Closed
Bug 1238815
Opened 8 years ago
Closed 8 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)
Tracking
()
RESOLVED
FIXED
mozilla48
People
(Reporter: decoder, Assigned: jolesen)
References
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()>
Updated•8 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•8 years ago
|
||
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)
Comment 3•8 years ago
|
||
(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)
Comment 4•8 years ago
|
||
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)
Assignee | ||
Comment 6•8 years ago
|
||
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
Comment 7•8 years ago
|
||
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)
Assignee | ||
Comment 8•8 years ago
|
||
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)
Comment 10•8 years ago
|
||
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)
Assignee | ||
Comment 11•8 years ago
|
||
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 12•8 years ago
|
||
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+
Updated•8 years ago
|
Flags: needinfo?(jdemooij)
Comment 14•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e53168052c2d
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in
before you can comment on or make changes to this bug.
Description
•