Closed
Bug 1100337
Opened 10 years ago
Closed 10 years ago
Assertion failure: buffer_ < end_, at js/src/jit/CompactBuffer.h:55 or Crash [@ CollectJitStackScripts]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
Tracking | Status | |
---|---|---|
firefox36 | --- | affected |
People
(Reporter: decoder, Assigned: shu)
References
Details
(4 keywords, Whiteboard: [jsbugmon:update][fuzzblocker])
Crash Data
Attachments
(2 files, 1 obsolete file)
4.51 KB,
patch
|
djvj
:
review+
|
Details | Diff | Splinter Review |
9.22 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision a52bf59965a0 (build with --enable-debug --enable-optimize --enable-posix-nspr-emulation --enable-valgrind, run with --thread-count=2 --ion-eager --ion-offthread-compile=off):
function $ERROR(msg) {
throw new Error("Test262 error: " + msg);
}
try {
$ERROR('#1.1: x >>>= 1 throw ReferenceError. Actual: ' + (2 << 4));
} catch (e) {}
var g = newGlobal();
g.parent = this;
g.eval("function f(frame, exc) { f2 = function () { return exc; }; exc = 123; }");
g.eval("new Debugger(parent).onExceptionUnwind = f;");
x = "1";
$ERROR('#1: x = "1"; x <<= 1; x === 2. Actual: ' + (x));
Backtrace:
Program terminated with signal 11, Segmentation fault.
#0 0x000000000069db74 in js::jit::CompactBufferReader::readByte (
this=<optimized out>)
at js/src/jit/CompactBuffer.h:55
55 MOZ_ASSERT(buffer_ < end_);
Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
#0 0x000000000069db74 in js::jit::CompactBufferReader::readByte (this=<optimized out>) at js/src/jit/CompactBuffer.h:55
#1 0x000000000061fc35 in readByte (this=<optimized out>) at js/src/jit/CompactBuffer.h:55
#2 readVariableLength (this=<optimized out>) at js/src/jit/CompactBuffer.h:40
#3 readUnsigned (this=<optimized out>) at js/src/jit/CompactBuffer.h:76
#4 js::jit::BaselineScript::nativeCodeForPC (this=0x32afd40, script=<optimized out>, pc=0x32d801c "\231\220\220\210\002ψ\006\214#", slotInfo=0x7fffefad249f) at js/src/jit/BaselineJIT.cpp:682
#5 0x000000000067251b in InitFromBailout (poppedLastSPSFrameOut=0x7fffefad296f, excInfo=<optimized out>, callPC=<synthetic pointer>, nextCallee=0x0, startFrameFormals=..., builder=..., invalidate=true, iter=..., ionScript=<optimized out>, script=0x7feba598cca0, fun=(JSFunction * const) 0x7feba5980840 [object Function "$ERROR"], callerPC=0x12 <Address 0x12 out of bounds>, caller=0x0, cx=0x31545a0) at js/src/jit/BaselineBailouts.cpp:1023
#6 js::jit::BailoutIonToBaseline (cx=0x31545a0, activation=<optimized out>, iter=..., invalidate=true, bailoutInfo=0x7fffefad2960, excInfo=0x7fffefad2b50, poppedLastSPSFrameOut=0x7fffefad296f) at js/src/jit/BaselineBailouts.cpp:1482
#7 0x00000000005b41b3 in js::jit::ExceptionHandlerBailout (cx=0x31545a0, frame=..., rfe=0x7fffefad32e0, excInfo=..., overrecursed=0x7fffefad2bde) at js/src/jit/Bailouts.cpp:201
rax 0x0 0
rbx 0x32d801c 53313564
rcx 0xa70b139d 140650096563101
rdx 0x0 0
rsi 0xa7385aa0 140650099530400
rdi 0xa7384180 140650099523968
rbp 0xefad1f40 140737214488384
rsp 0xefad1f40 140737214488384
r8 0xa83df740 140650116675392
r9 0x632d616c 8247338199356891500
r10 0x6a2f6c61 8246987515394747489
r11 0x0 0
r12 0x32afd40 53148992
r13 0x12e 302
r14 0x32afe50 53149264
r15 0x32d801c 53313564
rip 0x69db74 <js::jit::CompactBufferReader::readByte()+28>
=> 0x69db74 <js::jit::CompactBufferReader::readByte()+28>: movl $0x7b,0x0
0x69db7f <js::jit::CompactBufferReader::readByte()+39>: callq 0x4048b0 <abort@plt>
Updated•10 years ago
|
Flags: needinfo?(kvijayan)
Reporter | ||
Updated•10 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 1•10 years ago
|
||
JSBugMon: Bisection requested, result:
Due to skipped revisions, the first bad revision could be any of:
changeset: https://hg.mozilla.org/mozilla-central/rev/b160657339f8
user: Shu-yu Guo
date: Thu Nov 13 14:39:39 2014 -0800
summary: Bug 1032869 - Part 2: Move debuggee-ness to frames and selectively deoptimize when Debugger needs to observe execution. (r=jimb)
changeset: https://hg.mozilla.org/mozilla-central/rev/bb2f13ba7b1c
user: Shu-yu Guo
date: Thu Nov 13 14:39:40 2014 -0800
summary: Bug 1062629 - Off-thread compartment debug mode should match main thread compartment debug mode. (r=jimb)
changeset: https://hg.mozilla.org/mozilla-central/rev/1176cc3c3b34
user: Shu-yu Guo
date: Thu Nov 13 14:39:40 2014 -0800
summary: Bug 1063328 - Fix on-stack live iterator handling when bailing out in-place due to debug mode OSR. (r=jandem)
changeset: https://hg.mozilla.org/mozilla-central/rev/f8e316fa65bb
user: Shu-yu Guo
date: Thu Nov 13 14:39:40 2014 -0800
summary: Bug 1063330 - Remove the JS shell's evalInFrame. (r=jimb)
changeset: https://hg.mozilla.org/mozilla-central/rev/96a2f59f6ce4
user: Shu-yu Guo
date: Thu Nov 13 14:39:40 2014 -0800
summary: Bug 1032869 - Part 3: Don't consider onExceptionUnwind an all-execution-observing hook. (r=jandem)
This iteration took 363.220 seconds to run.
Reporter | ||
Comment 2•10 years ago
|
||
Needinfo from jimb also because this is jsdbg2. I still see this reproducing.
Flags: needinfo?(jimb)
Reporter | ||
Comment 3•10 years ago
|
||
This triggers quite often, can someone look into this fuzzblocker?
Whiteboard: [jsbugmon:update] → [jsbugmon:update][fuzzblocker]
![]() |
||
Comment 4•10 years ago
|
||
Shu-yu might have been looking at some related bugs recently... maybe he may also have an idea?
Flags: needinfo?(shu)
Keywords: regression
Assignee | ||
Comment 5•10 years ago
|
||
The bug is that in order to support onExceptionUnwind without deopting all code, whenever there's a live onExceptionUnwind hook, handling exceptions in Ion causes a bail out in place (instead of jumping to a catch/finally block) to Baseline, so that Baseline can do debug mode OSR and call the Debugger hook.
There's been a lot of corner cases in this in-place bailout I didn't think carefully enough through, sorry. :(
This bug is because the test case generate bytecode like so:
00018: 2 throw
00019: 2 retrval
retrval is unreachable, so there is no Baseline code for it. So when trying to bail out in place from the throw, which is a resumeAfter resume point, we assert when searching for the native code for retrval.
I'm not sure on the fix yet. It doesn't matter what we set the return address as, really, because this in-place bailout bails goes to the Baseline exception handler, and will not resume execution in the frame.
Flags: needinfo?(shu)
Flags: needinfo?(kvijayan)
Flags: needinfo?(jimb)
Assignee | ||
Comment 6•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → shu
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8527371 [details] [diff] [review]
Cheat when computing resume address for propagating exception for debug mode in Ion exception handler
Review of attachment 8527371 [details] [diff] [review]:
-----------------------------------------------------------------
I am not happy with this super-hacky approach. I don't have any better ones though. :(
Attachment #8527371 -
Flags: review?(jdemooij)
Assignee | ||
Comment 8•10 years ago
|
||
Consider a simple function like
function f() { throw 42; }
The bytecode for this is
main:
00000: int8 42
00002: throw
00003: retrval
JSOP_INT8 generates no native code, and JSOP_RETRVAL is unreachable, and so
generates no code either. So if we bail out in place after JSOP_THROW for
propagating an exception for the Debugger, we try to set the resume PC to be
JSOP_THROW per the first patch. However, since this has the same native code
offset as JSOP_INT8, the frame ends up thinking it's settled on JSOP_INT8.
This patch fixes 2 bugs:
1. When searching for a PC given a native offset, consider the last matching
entry instead of the first, since PCs that generate no code can't re-enter the
VM anyways.
2. Pad a nop after the prologue code to distinguish the return address of the
last NonOp ICEntry inserted in the prologue from the start address of the first
op, so that in the example above, baselineScriptAndPc won't think the frame is
settled on JSOP_INT8 because there's a NonOp IC from the prologue with the same
return address.
Assignee | ||
Updated•10 years ago
|
Attachment #8528054 -
Flags: review?(kvijayan)
Assignee | ||
Comment 9•10 years ago
|
||
Added test.
Attachment #8527371 -
Attachment is obsolete: true
Attachment #8527371 -
Flags: review?(jdemooij)
Attachment #8528062 -
Flags: review?(jdemooij)
Updated•10 years ago
|
Attachment #8528062 -
Flags: review?(jdemooij) → review+
Updated•10 years ago
|
Attachment #8528054 -
Flags: review?(kvijayan) → review+
Assignee | ||
Comment 10•10 years ago
|
||
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/df2462ab460b
https://hg.mozilla.org/mozilla-central/rev/4dffd706f975
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Updated•10 years ago
|
Target Milestone: mozilla37 → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•