Assertion failure: buffer_ < end_, at js/src/jit/CompactBuffer.h:55 or Crash [@ CollectJitStackScripts]

RESOLVED FIXED in mozilla36

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: decoder, Assigned: shu)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla36
x86_64
Linux
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 affected)

Details

(Whiteboard: [jsbugmon:update][fuzzblocker], crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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>
Flags: needinfo?(kvijayan)
(Reporter)

Updated

3 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 1

3 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

3 years ago
Needinfo from jimb also because this is jsdbg2. I still see this reproducing.
Flags: needinfo?(jimb)
(Reporter)

Comment 3

3 years ago
This triggers quite often, can someone look into this fuzzblocker?
Whiteboard: [jsbugmon:update] → [jsbugmon:update][fuzzblocker]
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

3 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

3 years ago
Created attachment 8527371 [details] [diff] [review]
Cheat when computing resume address for propagating exception for debug mode in Ion exception handler
(Assignee)

Updated

3 years ago
Assignee: nobody → shu
Status: NEW → ASSIGNED
(Assignee)

Comment 7

3 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

3 years ago
Created attachment 8528054 [details] [diff] [review]
Fix baseline PC mapping for bytecodes that generate no native code.

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

3 years ago
Attachment #8528054 - Flags: review?(kvijayan)
(Assignee)

Comment 9

3 years ago
Created attachment 8528062 [details] [diff] [review]
Cheat when computing resume address for propagating exception for debug mode in Ion exception handler.

Added test.
Attachment #8527371 - Attachment is obsolete: true
Attachment #8527371 - Flags: review?(jdemooij)
Attachment #8528062 - Flags: review?(jdemooij)

Updated

3 years ago
Attachment #8528062 - Flags: review?(jdemooij) → review+

Updated

3 years ago
Attachment #8528054 - Flags: review?(kvijayan) → review+
https://hg.mozilla.org/mozilla-central/rev/df2462ab460b
https://hg.mozilla.org/mozilla-central/rev/4dffd706f975
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37

Updated

3 years ago
Target Milestone: mozilla37 → mozilla36
Depends on: 1108145
Depends on: 1115844
You need to log in before you can comment on or make changes to this bug.