970262 - Assertion failure: isInRange(offset), at jit/arm/Assembler-arm.h:975 or Crash [@ ::jit::Assembler::bind]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision f550b112a19b (x86 ARM simulator build, run with --fuzzing-safe --ion-eager --ion-eager --ion-regalloc=backtracking --arm-sim-icache-checks):


var N = 70*0x1EDB ;
var x = build("&&")();
function build(operation)
{
  var a = [];
  for (var i = 1; i != N - 1; ++i)
    a.push("f()");
  return new Function(a.join(operation));
}

Comment 1

[Christian Holler (:decoder)]

Here's the crash trace:

Program received signal SIGSEGV, Segmentation fault.
js::jit::Assembler::bind (this=0xffffa580, label=0xf4891880, boff=...) at js/src/jit/arm/Assembler-arm.cpp:2268
2268    }
(gdb) bt
#0  js::jit::Assembler::bind (this=0xffffa580, label=0xf4891880, boff=...) at js/src/jit/arm/Assembler-arm.cpp:2268
#1  0x081a364e in emitBody (this=<optimized out>) at js/src/jit/BaselineCompiler.cpp:784
#2  js::jit::BaselineCompiler::compile (this=0xffffa56c) at js/src/jit/BaselineCompiler.cpp:95
#3  0x081a64b1 in js::jit::BaselineCompile (cx=0x9230530, script=0xf7533200) at js/src/jit/BaselineJIT.cpp:237
#4  0x081a675d in CanEnterBaselineJIT (cx=0x9230530, script=..., osr=false) at js/src/jit/BaselineJIT.cpp:301
#5  0x081a6831 in js::jit::CanEnterBaselineMethod (cx=0x9230530, state=...) at js/src/jit/BaselineJIT.cpp:358
#6  0x0821e6dc in js::jit::CanEnter (cx=0x9230530, state=...) at js/src/jit/Ion.cpp:2080
#7  0x08409abc in js::RunScript (cx=0x9230530, state=...) at js/src/vm/Interpreter.cpp:398
#8  0x0840a44b in RunScript (state=..., cx=0x9230530) at js/src/vm/Interpreter.cpp:390
#9  js::Invoke (cx=0x9230530, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:485
#10 0x0840af01 in js::Invoke (cx=0x9230530, thisv=..., fval=..., argc=0, argv=0xf7acbed8, rval=$jsval(-nan(0xfff8200000000))) at js/src/vm/Interpreter.cpp:522
#11 0x081a0a8e in js::jit::DoCallFallback (cx=0x9230530, frame=0xf7acbf00, stub=0x92b9698, argc=0, vp=0xf7acbec8, res=$jsval(-nan(0xfff8200000000))) at js/src/jit/BaselineIC.cpp:8104
#12 0x082cec05 in js::jit::Simulator::softwareInterrupt (this=0x922fbb8, instr=0x92db99c) at js/src/jit/arm/Simulator-arm.cpp:2088
#13 0x082cc2b5 in decodeType7 (instr=0x92db99c, this=0x922fbb8) at js/src/jit/arm/Simulator-arm.cpp:3058
#14 js::jit::Simulator::instructionDecode (this=0x922fbb8, instr=0x92db99c) at js/src/jit/arm/Simulator-arm.cpp:3847
#15 0x082cef4c in execute<false> (this=0x922fbb8) at js/src/jit/arm/Simulator-arm.cpp:3878
#16 js::jit::Simulator::callInternal (this=0x922fbb8, entry=0xf78bc648 "\361O-\351\020\213-\355\r\200\240\341h\220\235\345t\240\235", <incomplete sequence \345>)
    at js/src/jit/arm/Simulator-arm.cpp:3932
#17 0x082cf032 in js::jit::Simulator::call (this=0x922fbb8, entry=0xf78bc648 "\361O-\351\020\213-\355\r\200\240\341h\220\235\345t\240\235", <incomplete sequence \345>, argument_count=8)
    at js/src/jit/arm/Simulator-arm.cpp:3985
#18 0x081cad89 in EnterIon (data=..., cx=0x9230530) at js/src/jit/Ion.cpp:2235
(gdb) x /i $pc
=> 0x82a11ce <js::jit::Assembler::bind(js::jit::Label*, js::jit::BufferOffset)+174>:    mov    0x0,%eax


For the options, it suffices to use --fuzzing-safe --ion-eager, I forgot to cleanup the options in comment 0 before reporting. Marked s-s because I don't know if this is a simulator-only issue.

Comment 2

[Daniel Veditz [:dveditz]]

sec-high assuming this affects real ARM builds. If it's just the simulator then we can unhide the bug.

Comment 3

[Christian Holler (:decoder)]

Still seeing this, setting needinfo for Marty and dougc since this is ARM related :)

Comment 4

[Douglas Crosher [:dougc]]

The following reproduces in the simulator and on hardware.  It does not appear to be an issue with the simulator, rather a known limitation of labels on the ARM backend.  The test generates a huge BC code segment and the current label code can not represent the large offset.  This should be addresses in bug 972710, although it fails there too - looking into it.  Thank you for finding this.

var N = 70*0x1EDB ;
function build(operation)
{
  var a = [];
  for (var i = 1; i != N - 1; ++i)
    a.push("f()");
  return new Function(a.join(operation));
}
var x = build("&&")();

Comment 5

[Andrew McCreight [:mccr8]]

I'll assign this to you, Douglas, as it sounds like you are looking into it.

Comment 6

[Jan de Mooij [:jandem]]

Douglas, what's the status here? If you need help from Marty to fix this on m-c please needinfo/re-assign. Thanks!

Comment 7

[Douglas Crosher [:dougc]]

(In reply to Jan de Mooij [:jandem] from comment #6)
> Douglas, what's the status here? If you need help from Marty to fix this on
> m-c please needinfo/re-assign. Thanks!

It appears to be a known limitation of the current code, of the data structures, they can not encode the large offsets and this is being fixed in bug 972710, m-c eta 2 months.  Re-assigning to Marty as requested to explore further.

Comment 8

[Andrew McCreight [:mccr8]]

Marty, have you had a chance to look at this?

Comment 9

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
Due to skipped revisions, the first good revision could be any of:
changeset:   https://hg.mozilla.org/mozilla-central/rev/c8aaf280ddcc
parent:      173084:ddfdcf999cc2
user:        B2G Bumper Bot
date:        Tue Mar 11 14:30:22 2014 -0700
summary:     Bumping gaia.json for 2 gaia revision(s) a=gaia-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/3a9ec362452c
user:        B2G Bumper Bot
date:        Tue Mar 11 14:36:17 2014 -0700
summary:     Bumping manifests a=b2g-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/57ca6ea302e5
user:        B2G Bumper Bot
date:        Tue Mar 11 15:35:22 2014 -0700
summary:     Bumping gaia.json for 1 gaia revision(s) a=gaia-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/2cc4c8985c37
user:        B2G Bumper Bot
date:        Tue Mar 11 15:36:38 2014 -0700
summary:     Bumping manifests a=b2g-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/cfd08d9f7ffb
user:        Reuben Morais
date:        Tue Mar 11 19:41:48 2014 -0300
summary:     Bug 946239 - Divert download channels to the parent process. r=bz

changeset:   https://hg.mozilla.org/mozilla-central/rev/415d1bf2f7d5
user:        Reuben Morais
date:        Tue Mar 11 19:43:43 2014 -0300
summary:     Bug 946239 - Follow up, address review comment.

changeset:   https://hg.mozilla.org/mozilla-central/rev/503eb386e294
user:        B2G Bumper Bot
date:        Tue Mar 11 15:50:23 2014 -0700
summary:     Bumping gaia.json for 1 gaia revision(s) a=gaia-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/a8ef767cf756
user:        B2G Bumper Bot
date:        Tue Mar 11 15:51:40 2014 -0700
summary:     Bumping manifests a=b2g-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/ce5cf5cd98d4
user:        B2G Bumper Bot
date:        Tue Mar 11 16:40:23 2014 -0700
summary:     Bumping gaia.json for 1 gaia revision(s) a=gaia-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/af123358a93b
user:        B2G Bumper Bot
date:        Tue Mar 11 16:46:04 2014 -0700
summary:     Bumping manifests a=b2g-bump

changeset:   https://hg.mozilla.org/mozilla-central/rev/1a8fd5dc986a
parent:      173164:af123358a93b
parent:      173085:69fbe69ddb8c
user:        Wes Kocher
date:        Tue Mar 11 18:39:35 2014 -0700
summary:     Merge m-c to b-i

This iteration took 498.253 seconds to run.

Comment 10

[Christian Holler (:decoder)]

That doesn't look right. Maybe the issue went intermittent. Waiting for mjrosenb to investigate.

Comment 11

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Error: Failed to compile specified revision f550b112a19b (maybe try another?)

Comment 12

[Douglas Crosher [:dougc]]

This should be addressed with by the defensive code added in bug 1019684, so might resolved. Supporting large code objects is still to be addressed.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Douglas Crosher [:dougc] from comment #12)

Douglas can we close this bug?

Comment 14

[Douglas Crosher [:dougc]]

With the defensive code added in bug 1019684 the test case gives the following crash:
Assertion failure: [unhandlable oom] BOffImm, at /home/src/b2g/src/js/src/jscntxt.cpp:1384
Hit MOZ_CRASH() at /home/src/b2g/src/js/src/jscntxt.cpp:1385

I understand that this is an acceptable action when the code size exceeds the current limits.