Closed
Bug 1247832
Opened 8 years ago
Closed 8 years ago
Assertion failure: framePushed_ >= uint32_t(-value), at js/src/jit/MacroAssembler-inl.h:50
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: decoder, Assigned: bhackett1024)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [fuzzblocker] [jsbugmon:])
Attachments
(1 file)
725 bytes,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision ac39fba33c6d (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 --ion-offthread-compile=off --unboxed-arrays): for (;;)[0 | 3] Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08237c70 in adjustFrame (value=-16, this=0xffffbea0) at js/src/jit/MacroAssembler-inl.h:50 #0 0x08237c70 in adjustFrame (value=-16, this=0xffffbea0) at js/src/jit/MacroAssembler-inl.h:50 #1 js::jit::EmitUnstowICValues (masm=..., discard=false, values=2) at js/src/jit/arm/SharedICHelpers-arm.h:286 #2 0x0824c4c4 in js::jit::ICSetElemDenseOrUnboxedArrayAddCompiler::generateStubCode (this=0xffffc7c0, masm=...) at js/src/jit/BaselineIC.cpp:3267 #3 0x0841d1f9 in js::jit::ICStubCompiler::getStubCode (this=this@entry=0xffffc7c0) at js/src/jit/SharedIC.cpp:742 #4 0x0827ba94 in js::jit::ICSetElemDenseOrUnboxedArrayAddCompiler::getStubSpecific<2u> (this=this@entry=0xffffc7c0, space=space@entry=0xf4befc80, shapes=...) at js/src/jit/BaselineIC.cpp:8451 #5 0x08262ec7 in js::jit::ICSetElemDenseOrUnboxedArrayAddCompiler::getStub (this=this@entry=0xffffc7c0, space=0xf4befc80) at js/src/jit/BaselineIC.cpp:3066 #6 0x08264036 in js::jit::DoSetElemFallback (cx=0xf7a7d020, frame=0xf4ffff08, stub_=0xf4bfd060, stack=0xf4fffee8, objv=..., index=..., rhs=...) at js/src/jit/BaselineIC.cpp:2738 #7 0x084d1fa2 in js::jit::Simulator::softwareInterrupt (this=0xf7a7a000, instr=0xf4bf0344) at js/src/jit/arm/Simulator-arm.cpp:2368 #8 0x084d2226 in js::jit::Simulator::decodeType7 (this=0xf7a7a000, instr=0xf4bf0344) at js/src/jit/arm/Simulator-arm.cpp:3482 #9 0x084d01b5 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a7a000, instr=instr@entry=0xf4bf0344) at js/src/jit/arm/Simulator-arm.cpp:4404 #10 0x084d4044 in execute<false> (this=0xf7a7a000) at js/src/jit/arm/Simulator-arm.cpp:4459 #11 js::jit::Simulator::callInternal (this=this@entry=0xf7a7a000, entry=entry@entry=0xf7c88a70 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4547 #12 0x084d4565 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7c88a70 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4630 #13 0x08239fc6 in EnterBaseline (cx=cx@entry=0xf7a7d020, data=...) at js/src/jit/BaselineJIT.cpp:147 [...] #25 main (argc=5, argv=0xffffd8d4, envp=0xffffd8ec) at js/src/shell/js.cpp:7058 eax 0x0 0 ebx 0x9828438 159548472 ecx 0xf7e4388c -136038260 edx 0x0 0 esi 0xffffbea0 -16736 edi 0xffffbea0 -16736 ebp 0xffffbcb8 4294950072 esp 0xffffbca0 4294950048 eip 0x8237c70 <js::jit::EmitUnstowICValues(js::jit::MacroAssembler&, bool, int)+128> => 0x8237c70 <js::jit::EmitUnstowICValues(js::jit::MacroAssembler&, bool, int)+128>: movl $0x32,0x0 0x8237c7a <js::jit::EmitUnstowICValues(js::jit::MacroAssembler&, bool, int)+138>: call 0x80f9450 <abort()> This blocks ARM fuzzing with --unboxed-arrays, marking as fuzzblocker.
Updated•8 years ago
|
Whiteboard: [jsbugmon:update,bisect][fuzzblocker] → [fuzzblocker] [jsbugmon:bisect]
Comment 1•8 years ago
|
||
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Updated•8 years ago
|
Whiteboard: [fuzzblocker] [jsbugmon:bisect] → [fuzzblocker] [jsbugmon:]
Assignee | ||
Comment 3•8 years ago
|
||
This assertion is bogus, as it is tripping when we are compiling an error path where some things need to be popped from the stack, after another success path which popped those same things. The macro assembler sees both pops and gets confused. This patch fixes the assert but feels dirty. What's the point of this framePushed_ thing, and what safeguards are there to keep it from getting totally incoherent like this in the case of emitting code with non-trivial control flow?
Assignee: nobody → bhackett1024
Flags: needinfo?(bhackett1024)
Attachment #8724965 -
Flags: review?(jdemooij)
Comment 4•8 years ago
|
||
Comment on attachment 8724965 [details] [diff] [review] patch Review of attachment 8724965 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jit/BaselineIC.cpp @@ +3267,1 @@ > masm.bind(&failureUnstow); Can you just call masm.setFramePushed here? I think that's what we usually do. framePushed matters for Ion where we need to keep track of the frame size for the callee token. Baseline may also rely on it, not sure.
Attachment #8724965 -
Flags: review?(jdemooij) → review+
Comment 6•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c8261cc6c396
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in
before you can comment on or make changes to this bug.
Description
•