This seems unrelated to the small patch i ran on try: https://tbpl.mozilla.org/php/getParsedLog.php?id=47885561&tree=Try&full=1#error0 That log contains: > Assertion failure: *stack == reinterpret_cast<Rooted<void*>*>(this), at ../../../dist/include/js/RootingAPI.h:817 FWIW, this was on: https://tbpl.mozilla.org/?tree=Try&rev=831bd40616e4

Adding familiar names from hg history in the callstack here for possible ideas or ideas on who to ping.

08:26:40 WARNING - PROCESS-CRASH | /tests/dom/apps/tests/test_widget.html | application crashed [@ JS::Rooted<JSScript*>::~Rooted() + 0x1e] 08:26:40 INFO - Crash dump filename: /tmp/tmp9GFW0b/2f3deebe-c9ec-05aa-2c1d6734-245e66ef.dmp 08:26:40 INFO - Operating system: Android 08:26:40 INFO - 0.0.0 Linux 3.2.0+ #2 SMP PREEMPT Thu Nov 29 08:06:57 EST 2012 armv7l pandaboard/pandaboard/pandaboard:4.0.4/IMM76I/5:eng/test-keys 08:26:40 INFO - CPU: arm 08:26:40 INFO - 2 CPUs 08:26:40 INFO - Crash reason: SIGSEGV 08:26:40 INFO - Crash address: 0x0 08:26:40 INFO - Thread 14 (crashed) 08:26:40 INFO - 0 libxul.so!JS::Rooted<JSScript*>::~Rooted() + 0x1e 08:26:40 INFO - r4 = 0x00000000 r5 = 0x5da61af0 r6 = 0x00000012 r7 = 0x5da61778 08:26:40 INFO - r8 = 0x67e2aa9b r9 = 0x00000000 r10 = 0x5da61828 fp = 0x5da617b8 08:26:40 INFO - sp = 0x5da61740 lr = 0x62bfd59f pc = 0x62c0043e 08:26:40 INFO - Found by: given as instruction pointer in context 08:26:40 INFO - 1 libxul.so!js::jit::DoGetPropFallback [BaselineIC.cpp:831bd40616e4 : 6614 + 0x5] 08:26:40 INFO - r4 = 0x00000001 r5 = 0x5da61af0 r6 = 0x00000012 r7 = 0x5da61778 08:26:40 INFO - r8 = 0x67e2aa9b r9 = 0x00000000 r10 = 0x5da61828 fp = 0x5da617b8 08:26:40 INFO - sp = 0x5da61748 pc = 0x64064925 08:26:40 INFO - Found by: call frame info 08:26:40 INFO - 2 0x6052865a 08:26:40 INFO - r4 = 0x5da61af0 r5 = 0x5da61b08 r6 = 0x67c76f70 r7 = 0xffffff88 08:26:40 INFO - r8 = 0x00000183 r9 = 0x6d03e110 r10 = 0x00000000 fp = 0x5da61b4c 08:26:40 INFO - sp = 0x5da61ae8 pc = 0x6052865c 08:26:40 INFO - Found by: call frame info 08:26:40 INFO - 3 libxul.so!FT_GlyphLoader_Add [ftgloadr.c:831bd40616e4 : 359 + 0x5] 08:26:40 INFO - sp = 0x5da61b30 pc = 0x642c188b 08:26:40 INFO - Found by: stack scanning 08:26:40 INFO - Thread 0 08:26:40 INFO - 0 libc.so + 0xcff0 08:26:40 INFO - r4 = 0xffffffff r5 = 0x013b9204 r6 = 0x00000001 r7 = 0x000000fc 08:26:40 INFO - r8 = 0x00000000 r9 = 0x00000000 r10 = 0x013b91f0 fp = 0xffffffff 08:26:40 INFO - sp = 0xbeedb518 lr = 0x40187513 pc = 0x400fbff0 08:26:40 INFO - Found by: given as instruction pointer in context 08:26:40 INFO - 1 dalvik-heap (deleted) + 0x10b6 08:26:40 INFO - sp = 0xbeedb534 pc = 0x40b740b8 08:26:40 INFO - Found by: stack scanning 08:26:40 INFO - 2 libdvm.so + 0x60205 08:26:40 INFO - sp = 0xbeedb538 pc = 0x4095f207 08:26:40 INFO - Found by: stack scanning 08:26:40 INFO - 3 libdvm.so + 0xd9f42 08:26:40 INFO - sp = 0xbeedb540 pc = 0x409d8f44 08:26:40 INFO - Found by: stack scanning 08:26:40 INFO - 4 libdvm.so + 0x471a7 [...] ... thread 0 is not useful here.

I don't see any obvious non-LIFO uses of Rooted here. Seems to be ARM only. Is there maybe something wrong with baseline's stack manipulation here on ARM? Do either of you see anything suspicious that I'm missing?

(In reply to Terrence Cole [:terrence] from comment #3) Looks fine to me...

That's freaky. The same binary passed the test later. I just retriggered a bunch more runs, not that I expect to find much. It's very worrisome that there could be a rare code path that screws up LIFO. It would be interesting to see what the non-LIFO pointer value is. It's expecting the script from http://dxr.mozilla.org/mozilla-central/source/js/src/jit/BaselineIC.cpp#6589 but it's getting something else. It'd be nice to know if it is http://dxr.mozilla.org/mozilla-central/source/js/src/jit/BaselineIC.cpp#6549 or something entirely different. Sadly, I don't know how to figure that out. I downloaded the minidump, the symbols, and the apk, but I haven't the foggiest idea what to do with them. I can run minidump_stackwalk and get a proper stack out. Yay.

(In reply to Steve Fink [:sfink] from comment #5) > That's freaky. The same binary passed the test later. > > I just retriggered a bunch more runs, not that I expect to find much. > > It's very worrisome that there could be a rare code path that screws up LIFO. > > It would be interesting to see what the non-LIFO pointer value is. It's > expecting the script from > http://dxr.mozilla.org/mozilla-central/source/js/src/jit/BaselineIC.cpp#6589 > but it's getting something else. It'd be nice to know if it is > http://dxr.mozilla.org/mozilla-central/source/js/src/jit/BaselineIC.cpp#6549 > or something entirely different. That's a good thought! The last time we had the same crash it was a strict aliasing issue in an older GCC, so maybe there is an error path that gets the ordering wrong here or something. > Sadly, I don't know how to figure that out. I downloaded the minidump, the > symbols, and the apk, but I haven't the foggiest idea what to do with them. > I can run minidump_stackwalk and get a proper stack out. Yay. Maybe we could disassemble the binary and see if it is indeed gcc-vOld doing something we didn't expect?

Christian/Gary: does any of your ARM JS fuzzing create cases at all like the test that failed here? Seen this stack elsewhere?

Yes, I'm seeing this stack and I have it in my queue to reduce it. But it's not ARM only for me. Leaving the needinfo to supply a testcase here.

Hm, I just saw, my stacks look different: #0 Rooted (initial=<optimized out>, cx=0x3078ce0, this=0x7fff2cfc8d30) at ../../../dist/include/js/RootingAPI.h:753 #1 EvalInFrame (cx=0x3078ce0, argc=<optimized out>, vp=0x7fff2cfc9c78) at js/src/shell/js.cpp:2648 #2 0x0000000000868a72 in CallJSNative (args=..., native=0x410b70 <EvalInFrame(JSContext*, unsigned int, jsval*)>, cx=0x3078ce0) at js/src/jscntxtinlines.h:231 #3 js::Invoke (cx=0x3078ce0, args=..., construct=<optimized out>) at js/src/vm/Interpreter.cpp:482 #4 0x00000000008698ab in js::Invoke (cx=0x3078ce0, thisv=..., fval=..., argc=2, argv=<optimized out>, rval=...) at js/src/vm/Interpreter.cpp:538 #5 0x00000000005c35e7 in js::jit::DoCallFallback (cx=0x3078ce0, frame=0x7fff2cfc9f20, stub_=0x31d2e58, argc=2, vp=0x7fff2cfc9ec0, res=JSVAL_VOID) at js/src/jit/BaselineIC.cpp:8537 Is this likely the same issue I'm seeing here?

Not enough info to say at this point. If the error is in Do...CallFallback instead of the callee, then maybe. A regression range would be very helpful.

This seems like an intermittent issue that happened once. Is there some value in keeping this open, or is there just not enough to go on here?

Are the fuzzers still seeing crashes in ~Rooted?

Bug 1128603 is an assertion that has ~Rooted on the stack and given the assertion, this would likely lead to a crash in an optimized build.

Is that the right bug#? I don't see a ~Rooted there, just a crash when HeapReverser assumes an edge is an object when it's not.

I looked at the stack in question and it was simply a broken backtrace. I think this is fixed.

cc-ing bkerensa who could not see this and needs to for ESR release management.