Closed Bug 1238815 Opened 4 years ago Closed 4 years ago

Hit MOZ_CRASH(BOffImm offset out of range) at js/src/jit/arm/Assembler-arm.h:990 or Crash [@ js::jit::Assembler::bind]

Categories

(Core :: JavaScript Engine, defect, critical)

ARM
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox46 --- wontfix
firefox48 --- fixed

People

(Reporter: decoder, Assigned: jolesen)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [jsbugmon:update])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central revision 6020a4cb41a7 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-eager --arm-asm-nop-fill=1):

function test(s) eval("line0 = Error.lineNumber\ndebugger\n" + s);
function repeat(s) {
    return Array(87 << 14).join(s)
}
long_expr = repeat(" + i")
long_throw_stmt = long_expr;
test(long_throw_stmt);



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x08453510 in js::jit::BOffImm::BOffImm (this=0xffffa028, offset=193855412) at js/src/jit/arm/Assembler-arm.h:990
#0  0x08453510 in js::jit::BOffImm::BOffImm (this=0xffffa028, offset=193855412) at js/src/jit/arm/Assembler-arm.h:990
#1  0x084521be in diffB<js::jit::BOffImm> (other=..., this=<synthetic pointer>) at js/src/jit/shared/IonAssemblerBuffer.h:51
#2  js::jit::Assembler::bind (this=this@entry=0xffffa32c, label=label@entry=0xffffacac, boff=boff@entry=...) at js/src/jit/arm/Assembler-arm.cpp:2778
#3  0x0889d913 in js::jit::BaselineCompiler::emitEpilogue (this=this@entry=0xffffa320) at js/src/jit/BaselineCompiler.cpp:451
#4  0x088c1e77 in js::jit::BaselineCompiler::compile (this=this@entry=0xffffa320) at js/src/jit/BaselineCompiler.cpp:118
#5  0x0823c484 in js::jit::BaselineCompile (cx=cx@entry=0xf7a78020, script=0xf5754280, forceDebugInstrumentation=false) at js/src/jit/BaselineJIT.cpp:280
#6  0x0823cbb1 in CanEnterBaselineJIT (cx=cx@entry=0xf7a78020, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0) at js/src/jit/BaselineJIT.cpp:319
#7  0x0823cd7d in js::jit::CanEnterBaselineMethod (cx=cx@entry=0xf7a78020, state=...) at js/src/jit/BaselineJIT.cpp:383
#8  0x0830e173 in js::jit::CanEnter (cx=cx@entry=0xf7a78020, state=...) at js/src/jit/Ion.cpp:2606
#9  0x086b4b9d in js::RunScript (cx=cx@entry=0xf7a78020, state=...) at js/src/vm/Interpreter.cpp:400
#10 0x086ba169 in js::ExecuteKernel (cx=cx@entry=0xf7a78020, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., type=type@entry=js::EXECUTE_DIRECT_EVAL, evalInFrame=evalInFrame@entry=..., result=0xf59ffd88) at js/src/vm/Interpreter.cpp:683
#11 0x0821da2b in EvalKernel (cx=cx@entry=0xf7a78020, args=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., scopeobj=..., scopeobj@entry=..., pc=0xf7aad26f "{") at js/src/builtin/Eval.cpp:334
#12 0x0821e15e in js::DirectEval (cx=cx@entry=0xf7a78020, args=...) at js/src/builtin/Eval.cpp:442
#13 0x08250e29 in js::jit::DoCallFallback (cx=cx@entry=0xf7a78020, frame=frame@entry=0xf59ffdc8, stub_=stub_@entry=0xf55679e0, argc=argc@entry=1, vp=vp@entry=0xf59ffd88, res=res@entry=...) at js/src/jit/BaselineIC.cpp:6170
#14 0x084f697e in js::jit::Simulator::softwareInterrupt (this=0xf7a77000, instr=0xf551d234) at js/src/jit/arm/Simulator-arm.cpp:2360
#15 0x084f6c66 in js::jit::Simulator::decodeType7 (this=0xf7a77000, instr=0xf551d234) at js/src/jit/arm/Simulator-arm.cpp:3482
#16 0x084f4c25 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a77000, instr=instr@entry=0xf551d234) at js/src/jit/arm/Simulator-arm.cpp:4404
#17 0x084f8a24 in execute<false> (this=0xf7a77000) at js/src/jit/arm/Simulator-arm.cpp:4459
#18 js::jit::Simulator::callInternal (this=this@entry=0xf7a77000, entry=entry@entry=0xf7fc9340 "\377\377\377\352\360O-\351\377\377\377\352\004\320M\342\377\377\377\352\020\212-\355\377\377\377\352\r\200\240\341\377\377\377\352h\220\235\345\377\377\377\352\r\260\240\341\377\377\377\352t\240\235\345\377\377\377", <incomplete sequence \352>) at js/src/jit/arm/Simulator-arm.cpp:4547
#19 0x084f8eb5 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc9340 "\377\377\377\352\360O-\351\377\377\377\352\004\320M\342\377\377\377\352\020\212-\355\377\377\377\352\r\200\240\341\377\377\377\352h\220\235\345\377\377\377\352\r\260\240\341\377\377\377\352t\240\235\345\377\377\377", <incomplete sequence \352>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4630
#20 0x0822fe8b in EnterBaseline (cx=cx@entry=0xf7a78020, data=...) at js/src/jit/BaselineJIT.cpp:135
[...]
#43 main (argc=6, argv=0xffffcdf4, envp=0xffffce10) at js/src/shell/js.cpp:6918
eax	0x0	0
ebx	0x980943c	159421500
ecx	0xf7e3b88c	-136071028
edx	0x0	0
esi	0xffffa32c	-23764
edi	0x8cc	2252
ebp	0xffff9fe8	4294942696
esp	0xffff9fd0	4294942672
eip	0x8453510 <js::jit::BOffImm::BOffImm(int)+80>
=> 0x8453510 <js::jit::BOffImm::BOffImm(int)+80>:	movl   $0x3de,0x0
   0x845351a <js::jit::BOffImm::BOffImm(int)+90>:	call   0x80f8c10 <abort()>
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160205030110" and the hash "30c8ec933737ed7fde559d50815d3f7222067e3d".
The "bad" changeset has the timestamp "20160205032410" and the hash "e2fa804302c9a34576754dd73cab80b7c718701d".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=30c8ec933737ed7fde559d50815d3f7222067e3d&tochange=e2fa804302c9a34576754dd73cab80b7c718701d
Jan, is bug 1245767 a likely regressor?
Blocks: 1245767
Flags: needinfo?(jdemooij)
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> Jan, is bug 1245767 a likely regressor?

Nope, bug 1245767 landed last Friday and this bug was filed last month.

I think we're creating a huge Baseline script here, and the ARM assembler buffer is unable to create branches with a target distance > ~32 MB. We should probably add some kind of limit somewhere...
No longer blocks: 1245767
Flags: needinfo?(jdemooij)
Naveed can you help find an owner for this bug? Or someone to have another look. Thanks!
Flags: needinfo?(nihsanullah)
Setting needinfo? from Jakob since this seems to involve ARM.
Flags: needinfo?(jolesen)
Jan's analysis is correct. The ARM assembler has a size limit.

Something similar was fixed for asm.js in bug 1240583.
Flags: needinfo?(jolesen)
See Also: → 1240583
Jakob assign to you. What is the solution here? Extend the ARM assembler limit or have Baseline chunkify scripts first especially for ARM? Doex x86 have a limit? If so what is it?
Assignee: nobody → jolesen
Flags: needinfo?(nihsanullah) → needinfo?(jolesen)
The limit is inherent to the ARM instruction set, so it can't be extended. ARM branch instructions can't jump more than 32 MB in either direction. The corresponding limit in the x86 and x86-64 instruction sets is 2 GB, so it doesn't come up.

ARM64 has much tighter branch ranges (1 MB IIRC), so I had to implement veneer insertion for that target in bug 1210554. This was a lot of work.

The 32-bit ARM assembler just assumes we will never hit the 32 MB limit, and it crashes (BOffImm offset out of range) if we do anyway.

I don't think it is worthwhile spending the same effort on inserting veneers for 32-bit ARM that we did for 64-bit ARM. We should just abandon scripts that create more than 32 MB of code.

Jan, is it possible to abort Baseline / Ion compilation when a function grows too large?
Flags: needinfo?(jolesen) → needinfo?(jdemooij)
Can we get a fix or a backout asap!
Flags: needinfo?(nihsanullah)
I'll look into this asap (keeping the NI), but it's a safe crash, much older than current beta, and very unlikely to show up in the wild.
Flags: needinfo?(nihsanullah)
ARM branch instructions have a limited range of 32 MB, and our ARM
macroassembler doesn't mitigate that except by crashing when a branch goes out
of range.

Limit the size of scripts that baseline will attempt to compile on ARM so that
we are much less likely to hit the hard crash.

Review commit: https://reviewboard.mozilla.org/r/40819/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/40819/
Attachment #8731765 - Flags: review?(jdemooij)
Comment on attachment 8731765 [details]
MozReview Request: Bug 1238815 - Limit baseline script size on ARM. r?jandem

https://reviewboard.mozilla.org/r/40819/#review37887

Looks good. Main worry is large (Emscripten-)generated functions hitting this, but 1 MB of bytecode is a lot and we can deal with that if it turns out to be a problem.
Attachment #8731765 - Flags: review?(jdemooij) → review+
Flags: needinfo?(jdemooij)
https://hg.mozilla.org/mozilla-central/rev/e53168052c2d
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.