1247832 - Assertion failure: framePushed_ >= uint32_t(-value), at js/src/jit/MacroAssembler-inl.h:50

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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.

Comment 1

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

ni? bhackett because of unboxed arrays.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

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?

Comment 4

[Jan de Mooij [:jandem]]

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.

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c8261cc6c396

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c8261cc6c396