Closed
Bug 1242840
Opened 9 years ago
Closed 9 years ago
Crash [@ JSObject::as<js::ClonedBlockObject>] with OOM
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla47
People
(Reporter: decoder, Assigned: jonco)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(1 file)
(deleted),
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision c2256ee8ae9a (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager):
enableSPSProfiling()
oomTest(() => {
try {
for (quit of ArrayBuffer);
} catch (e) {
switch (1) {
case 0:
let x
case 1:
(function() x)()
}
}
})
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
JSObject::as<js::ClonedBlockObject> (this=0x0) at js/src/jsobj.h:546
#0 JSObject::as<js::ClonedBlockObject> (this=0x0) at js/src/jsobj.h:546
#1 0x0000000000ad627c in js::ScopeIter::settle (this=this@entry=0x7fffffffb3a0) at js/src/vm/ScopeObject.cpp:1473
#2 0x0000000000ad699e in js::ScopeIter::operator++ (this=this@entry=0x7fffffffb3a0) at js/src/vm/ScopeObject.cpp:1501
#3 0x0000000000a2e3fb in js::UnwindAllScopesInFrame (cx=cx@entry=0x7ffff6907800, si=...) at js/src/vm/Interpreter.cpp:994
#4 0x00000000007f188e in js::jit::DebugEpilogue (cx=cx@entry=0x7ffff6907800, frame=frame@entry=0x7fffffffbb08, pc=0x7ffff318e88c "\214", ok=ok@entry=false) at js/src/jit/VMFunctions.cpp:690
#5 0x00000000006dcbbc in js::jit::OnLeaveBaselineFrame (cx=cx@entry=0x7ffff6907800, frame=..., pc=<optimized out>, rfe=rfe@entry=0x7fffffffba98, frameOk=frameOk@entry=false) at js/src/jit/JitFrames.cpp:525
#6 0x0000000000701777 in HandleExceptionBaseline (pc=0x7ffff318e88c "\214", rfe=<optimized out>, frame=..., cx=0x7ffff6907800) at js/src/jit/JitFrames.cpp:758
#7 js::jit::HandleException (rfe=<optimized out>) at js/src/jit/JitFrames.cpp:899
#8 0x00007ffff7fe8608 in ?? ()
#9 0x0000000000000008 in ?? ()
#10 0x00007fffffffba98 in ?? ()
#11 0x0000000000000000 in ?? ()
rax 0x7ffff7e6a1c0 140737352475072
rbx 0x7fffffffb3a0 140737488335776
rcx 0x7ffff7e660a0 140737352458400
rdx 0x1 1
rsi 0x2 2
rdi 0x0 0
rbp 0x7fffffffb320 140737488335648
rsp 0x7fffffffb2f0 140737488335600
r8 0x7fffffffb390 140737488335760
r9 0xa 10
r10 0x1 1
r11 0x7ffff695d1e0 140737330401760
r12 0x7ffff7e6a1c0 140737352475072
r13 0x7ffff7e6a1c0 140737352475072
r14 0x7fffffffbb08 140737488337672
r15 0x7ffff318e88c 140737271883916
rip 0x7e45f1 <JSObject::as<js::ClonedBlockObject>()+1>
=> 0x7e45f1 <JSObject::as<js::ClonedBlockObject>()+1>: mov (%rdi),%rdx
0x7e45f4 <JSObject::as<js::ClonedBlockObject>()+4>: lea 0x13b5685(%rip),%rax # 0x1b99c80 <_ZN2js17ClonedBlockObject6class_E>
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•9 years ago
|
||
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===
The "good" changeset has the timestamp "20151013053056" and the hash "8d9c20c241be7d7b3cfa90a3368a77db42172781".
The "bad" changeset has the timestamp "20151013054956" and the hash "d80f9d6921f8209ef01aa730be9a97ab727704d1".
Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d9c20c241be7d7b3cfa90a3368a77db42172781&tochange=d80f9d6921f8209ef01aa730be9a97ab727704d1
Not sure if this is exactly the same as bug 1241731, but both involve "clones", so setting s-s since that bug is s-s, and setting needinfo? from Jon as a start (since he's fixing that bug too).
(I was unable to reproduce this quickly on Mac builds fwiw)
Group: javascript-core-security
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 3•9 years ago
|
||
This bug is unrelated and the testcase doesn't fail without that assertion, even under valgrind. Clearing s-s.
Assignee: nobody → jcoppeard
Group: javascript-core-security
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 4•9 years ago
|
||
Patch to change jit::Invalidate() to skip calling the profiler's markEvent() method if we hit OOM. I'm pretty sure that this will not cause problems.
This let me make Invalidate() infallible, and a whole chain of other things followed.
Attachment #8712135 -
Flags: review?(jdemooij)
Comment 5•9 years ago
|
||
Comment on attachment 8712135 [details] [diff] [review]
bug1242840-profiler-oom
Review of attachment 8712135 [details] [diff] [review]:
-----------------------------------------------------------------
Nice fix!
Attachment #8712135 -
Flags: review?(jdemooij) → review+
Comment 7•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment 8•9 years ago
|
||
bugherder |
Too late to uplift to 46, we are just at the end of the cycle heading into beta 11.
You need to log in
before you can comment on or make changes to this bug.
Description
•