Closed Bug 970262 Opened 9 years ago Closed 8 years ago

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

Categories

(Core :: JavaScript Engine, defect)

ARM
Linux
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox30 --- affected

People

(Reporter: decoder, Assigned: mjrosenb)

References

Details

(Keywords: assertion, sec-high, testcase, Whiteboard: [jsbugmon:])

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));
}
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.
sec-high assuming this affects real ARM builds. If it's just the simulator then we can unhide the bug.
Keywords: sec-high
Blocks: 959597
No longer blocks: IonFuzz
Assignee: general → nobody
Still seeing this, setting needinfo for Marty and dougc since this is ARM related :)
Flags: needinfo?(mrosenberg)
Flags: needinfo?(dtc-moz)
Group: javascript-core-security
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("&&")();
Blocks: 972710
No longer blocks: 959597
Flags: needinfo?(mrosenberg)
Flags: needinfo?(dtc-moz)
I'll assign this to you, Douglas, as it sounds like you are looking into it.
Assignee: nobody → dtc-moz
No longer blocks: 972710
Depends on: 972710
Douglas, what's the status here? If you need help from Marty to fix this on m-c please needinfo/re-assign. Thanks!
Flags: needinfo?(dtc-moz)
(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.
Assignee: dtc-moz → mrosenberg
Flags: needinfo?(dtc-moz)
Marty, have you had a chance to look at this?
Flags: needinfo?(mrosenberg)
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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.
That doesn't look right. Maybe the issue went intermittent. Waiting for mjrosenb to investigate.
Whiteboard: [jsbugmon:update] → [jsbugmon:]
JSBugMon: Cannot process bug: Error: Failed to compile specified revision f550b112a19b (maybe try another?)
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.
(In reply to Douglas Crosher [:dougc] from comment #12)

Douglas can we close this bug?
Flags: needinfo?(dtc-moz)
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dtc-moz)
Resolution: --- → WORKSFORME
Flags: needinfo?(mrosenberg)
Group: javascript-core-security
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.