Closed Bug 800935 Opened 12 years ago Closed 12 years ago

Assertion failure: masm.framePushed() == initialStack, at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:522


(Core :: JavaScript Engine, defect)

Not set





(Reporter: kats, Assigned: djvj)





(1 file)

On a local Fennec debug build from an Oct 11 m-c changeset + a few local changes to browser.js, I got a crash while panning down on (I was somewhere near the end of the article after having panned down).

The logcat reported an assertion failure in IonCaches.cpp:

10-12 11:05:37.281 D/dalvikvm( 2630): GC_CONCURRENT freed 1272K, 10% free 14891K/16391K, paused 3ms+6ms, total 47ms
10-12 11:05:37.929 F/MOZ_Assert( 2630): Assertion failure: masm.framePushed() == initialStack, at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:522
10-12 11:05:37.929 F/libc    ( 2630): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 2647 (Gecko)
10-12 11:05:38.031 I/DEBUG   (21008): unexpected waitpid response: n=2647, status=00000b00
10-12 11:05:38.031 I/DEBUG   (21008): ptrace detach from 2647 failed: No such process
10-12 11:05:38.031 I/DEBUG   (21008): debuggerd committing suicide to free the zombie!
10-12 11:05:38.046 I/DEBUG   ( 2806): debuggerd: Jul  4 2012 21:03:21
10-12 11:05:38.109 I/WindowState(  304): WIN DEATH: Window{418a4308 org.mozilla.fennec_kats/org.mozilla.fennec_kats.App paused=false}
10-12 11:05:38.109 I/ActivityManager(  304): Process org.mozilla.fennec_kats (pid 2630) has died.

I've tried to reproduce it once with gdb attached but I ran into a different crash in the gfx code. I'll try again in a bit.
Ok, I managed to reproduce it. gdb backtrace is:

(gdb) bt
#0  0x647cde74 in GetNativePropertyStub::generateCallGetter (this=0x5e4c1cfc, cx=0x696b6a00, masm=..., obj=0x697609c0, propName=0x618bce00, holder=0x69760560, shape=0x67e97a60, liveRegs=..., 
    object=..., output=..., outputTypes=0x65bb5570, returnAddr=0x5cd52250, pc=0x695f7471 "5", failures=0x5e4c1d74, nonRepatchFailures=0x0) at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:522
#1  0x647d37a0 in js::ion::IonCacheGetProperty::attachCallGetter (this=0x6b0c9cb0, cx=0x696b6a00, ion=0x6b0c9800, obj=0x697609c0, holder=0x69760560, shape=0x67e97a60, safepointIndex=0x6b0c9bc4, 
    returnAddr=0x5cd52250) at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:603
#2  0x647d417c in TryAttachNativeStub (isCacheable=<synthetic pointer>, returnAddr=0x5cd52250, safepointIndex=0x6b0c9bc4, name=..., obj=..., cache=..., ion=0x6b0c9800, cx=0x696b6a00)
    at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:708
#3  js::ion::GetPropertyCache (cx=0x696b6a00, cacheIndex=<optimized out>, obj=..., vp=...) at /Users/kats/zspace/mozilla-git/js/src/ion/IonCaches.cpp:741
#4  0x5cd513d0 in ?? ()
#5  0x5cd513d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Full STR that make it reproduce for me are below. I don't know how much the first two page loads affect ionmonkey state so I'm including them for completeness, but it's possible that the bug can be reproduced just using the last URL.

1. Load on a Galaxy Nexus running android 4.1
2. Start the "Fennec kats" app
3. Load
4. Long tap on "The game of life emulated in the game of life" (currently item #1 on HN, url is and select "Open link in new tab"
5. Switch to the newly opened tab and scroll down a bit
6. Switch back to the HN tab
7. Long tap on "Why I Two-Space" (currently item #2 on HN, url is and select "Open link in new tab"
8. Switch to the newly opened tab and scroll down the page
9. Crash!
This doesn't replicate on x86, so I'm guessing it's either an ARM-specific or device-specific thing.  I'm hoping it's just ARM-specific.
Notes taken from kats' debug build stacktrace:  initialStack = 156, framePushed = 152, sizeof(IonOOLPropertyOpExitFrame) = 36.
I'm pretty sure I found the problem, needs testing to verify.

The |buildOOLFakeExitFrame| implementation for ARM doesn't use the capital |Push| method to push args - instead it uses the lowercase |push| method - for the fakeReturnAddr.  The former tracks compile-time frame size, the latter does not.  Because of this, the |framePushed| in masm isn't incremented for that push.

Later on, when we adjust the |framePushed| down by the size of the PropertyOp exit frame, we subtract the correct amount, and thus |framePushed| becomes unsynced.

tl;dr: We don't account for a push of a value in the frame, but do account for that value's pop, so the JS_ASSERT that checks that accounting fails.
Assignee: general → kvijayan
Attached patch Fix.Splinter Review
Patch seems to work for me. I can't 100% guarantee it since the bug wasn't 100% reproducible, though.
Attachment #670869 - Flags: review?(nicolas.b.pierron)
Attachment #670869 - Flags: review?(nicolas.b.pierron) → review+
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.