715149 - Assertion failure: [infer failure] Missing type pushed 0: void

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

1. http://www.grin.com/profile/395409/griseldis-wedel in Nightly Mac && Linux
2. Assertion failure: [infer failure] Missing type pushed 0: void, at /work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:349

I can reproduce on mac with a locally saved case. I'll reduce and attach.

pseudo signature/stacks:

JS_Assert | js::types::TypeFailure js::types::TypeScript::CheckBytecode TypeCheckNextBytecode js::Interpret js::RunScript

JS_Assert | js::types::TypeFailure js::Shape::search js::Shape::base js::gc::Cell::arenaHeader js::CompartmentChecker::check

Note Windows 7 crashed once with an apparently different stack though I can't reproduce it:

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 37 stepping 1
     1 CPU

Crash reason:  EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x4

Thread 0 (crashed)
 0  mozjs.dll!js::HeapPtr<js::types::TypeObject,unsigned int>::operator->() [Barrier.h : 229 + 0xa]
    eip = 0x68f42a5a   esp = 0x00258548   ebp = 0x0025854c   ebx = 0x09a73440
    esi = 0x099bdd50   edi = 0x0000c000   eax = 0x00000004   ecx = 0x00000004
    edx = 0xffffff87   efl = 0x00210202
    Found by: given as instruction pointer in context
 1  mozjs.dll!JSObject::hasSingletonType() [jsobj.h : 803 + 0x11]
    eip = 0x68f30e42   esp = 0x00258554   ebp = 0x00258558
    Found by: call frame info
 2  mozjs.dll!js::types::Type::ObjectType(JSObject *) [jsinferinlines.h : 65 + 0x7]
    eip = 0x68f51edb   esp = 0x00258560   ebp = 0x00258560
    Found by: call frame info
 3  mozjs.dll!js::types::GetValueType(JSContext *,JS::Value const &) [jsinferinlines.h : 91 + 0x11]
    eip = 0x68f51dc9   esp = 0x00258568   ebp = 0x00258570
    Found by: call frame info
 4  mozjs.dll!js::types::TypeScript::SetArgument(JSContext *,JSScript *,unsigned int,JS::Value const &) [jsinferinlines.h : 689 + 0x10]
    eip = 0x68fa0ac4   esp = 0x00258578   ebp = 0x00258588
    Found by: call frame info

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: testcase assertion

Assertion failure: [infer failure] Missing type pushed 0: void, at /work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:349

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x074e949d in CrashInJS () at /work/mozilla/builds/nightly/mozilla/js/src/jsutil.cpp:95
95	    *((volatile int *) NULL) = 123;  /* To continue from here in GDB: "return" then "continue". */
(gdb) bt
#0  0x074e949d in CrashInJS () at /work/mozilla/builds/nightly/mozilla/js/src/jsutil.cpp:95
#1  0x074e9507 in JS_Assert (s=0xbfff3cfc "[infer failure] Missing type pushed 0: void", file=0x78b30e0 "/work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp", ln=349) at /work/mozilla/builds/nightly/mozilla/js/src/jsutil.cpp:115
#2  0x073e988f in js::types::TypeFailure (cx=0x1f65a900, fmt=0x78b428c "Missing type pushed %u: %s") at /work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:349
#3  0x073e9a67 in js::types::TypeScript::CheckBytecode (cx=0x1f65a900, script=0x1ac3d258, pc=0x255028fc "V", sp=0x1b14aac8) at /work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:5635
#4  0x07403482 in TypeCheckNextBytecode (cx=0x1f65a900, script=0x1ac3d258, n=3, regs=@0xbfff4950) at /work/mozilla/builds/nightly/mozilla/js/src/jsinterp.cpp:1434
#5  0x0741492c in js::Interpret (cx=0x1f65a900, entryFrame=0x1b14a940, interpMode=js::JSINTERP_NORMAL) at /work/mozilla/builds/nightly/mozilla/js/src/jsinterp.cpp:3858
#6  0x0741dad7 in js::RunScript (cx=0x1f65a900, script=0x1ac43848, fp=0x1b14a940) at /work/mozilla/builds/nightly/mozilla/js/src/jsinterp.cpp:478
#7  0x0741e297 in js::InvokeKernel (cx=0x1f65a900, args={<js::CallReceiver> = {usedRval_ = false, argv_ = 0x1b14a920}, argc_ = 2}, construct=js::NO_CONSTRUCT) at /work/mozilla/builds/nightly/mozilla/js/src/jsinterp.cpp:541

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: testcase crash

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
0x0744c029 in js::HeapPtr<js::types::TypeObject, unsigned long>::operator-> (this=0x4) at gc/Barrier.h:229
229	    T *operator->() const { return value; }
(gdb) bt
#0  0x0744c029 in js::HeapPtr<js::types::TypeObject, unsigned long>::operator-> (this=0x4) at gc/Barrier.h:229
#1  0x073f1fa8 in JSObject::hasSingletonType (this=0x0) at jsobj.h:808
#2  0x0744edb9 in js::types::Type::ObjectType (obj=0x0) at jsinferinlines.h:65
#3  0x073f5a82 in js::types::GetValueType (cx=0x1f65a0b0, val=@0x1b14aac0) at jsinferinlines.h:91
#4  0x073ffed3 in js::types::TypeScript::SetArgument (cx=0x1f65a0b0, script=0x1ac40388, arg=0, value=@0x1b14aac0) at jsinferinlines.h:689
#5  0x073ee6e3 in js::types::TypeMonitorCallSlow (cx=0x1f65a0b0, callee=0x1ac4f660, args=@0xbfff3eec, constructing=false) at /work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:5033
#6  0x0742213a in js::types::TypeMonitorCall (cx=0x1f65a0b0, args=@0xbfff3eec, constructing=false) at jsinferinlines.h:330
#7  0x0765342e in UncachedInlineCall (f=@0xbfff4040, initial=js::INITIAL_NONE, pret=0xbfff3fc0, unjittable=0xbfff3fc4, argc=2) at /work/mozilla/builds/nightly/mozilla/js/src/methodjit/InvokeHelpers.cpp:323
#8  0x0765381e in js::mjit::stubs::UncachedCallHelper (f=@0xbfff4040, argc=2, lowered=false, ucr=0xbfff3fbc) at /work/mozilla/builds/nightly/mozilla/js/src/methodjit/InvokeHelpers.cpp:475
#9  0x0763748f in CallCompiler::update (this=0xbfff4020) at /work/mozilla/builds/nightly/mozilla/js/src/methodjit/MonoIC.cpp:989
#10 0x076315f0 in js::mjit::ic::Call (f=@0xbfff4040, ic=0xbfb54c) at /work/mozilla/builds/nightly/mozilla/js/src/methodjit/MonoIC.cpp:1047
#11 0x2549fe2e in ?? ()
#12 0x0759aff9 in js::mjit::EnterMethodJIT (cx=0x3, fp=0x1ac2d040, code=0x1b14aa00, stackLimit=0x75998b8, partial=false) at /work/mozilla/builds/nightly/mozilla/js/src/methodjit/MethodJIT.cpp:1034
Previous frame inner to this frame (gdb could not unwind past this frame)

Comment 3

[Daniel Veditz [:dveditz]]

Guessing from history that missing types can be exploited

Comment 4

[Daniel Veditz [:dveditz]]

I don't crash in Firefox 9/10/11 on Mac. Marcia crashed on Nightly with a December build, but not after she updated. Fixed/worksforme?

Would be nice to pin down the regression range so that
 - we're sure old branches are not affected
 - won't accidentally infect old branches later should
   whatever bug that caused it be backported for stability reasons

Would be nice to find the fix range so that
 - we can be sure we really fixed it, not accidentally masked it
 - can link the fix to the regressing bug as a "depends on" just in
   case of the backport scenario above.

Comment 5

[Daniel Veditz [:dveditz]]

qawanted: need regression and fix ranges per comment 4

Comment 6

[Bob Clary [:bc] (inactive)]

http://www.emusic.com/listen/#/album/gela/margaritas-amarillas/12829333/ asserts Beta/10, Aurora/11, Nightly/12 on Mac OS X and Linux. It seems you have to exit the browser or change the page after the load event fires but before the page completes rendering to reproduce however. 

The easiest way to reproduce is to use Spider (http://bclary.com/projects/spider/spider/spider.xpi) but it is not required.

firefox -spider -start -quit -url http://www.emusic.com/listen/#/album/gela/margaritas-amarillas/12829333/

works for me pretty consistently locally with aurora and nightly on Linux though I can't reproduce with a saved version of the page.

Comment 7

[Brian Hackett [Laid off!]]

I was able to repro with the spider instructions.  I don't get the missing type pushed: void (can you attach the debug spew you get with that failure) but get a different missing pushed type at a JSOP_NEWARRAY, which I was able to confirm was due to running code against a global with a cleared scope.  This is the same problem as bug 711695.

Comment 8

[Bob Clary [:bc] (inactive)]

I haven't been able to reproduce the missing type pushed: void error which I got initially during the test case reduction. I've been retesting my missing type assertions and only been able to get missing type: pushed 0. I'll keep trying as time permits.

Comment 9

[Bob Clary [:bc] (inactive)]

Wow. I didn't intentionally reset the flags. I guess my old stale tab for this bug is responsible. restoring... I don't have permission to reset tracking-firefox13 though. sorry.

Comment 10

[Alex Keybl [:akeybl]]

After bug 637099 has landed on trunk, we'll evaluate whether to take a fix on ESR10.

Comment 11

[Daniel Veditz [:dveditz]]

resolving based on bug 637099 landing

Comment 12

[Alex Keybl [:akeybl]]

Although we won't be landing this fix on the ESR until FF13 is on mozilla-beta, the sooner we prepare the patches associated with bug 637099 for ESR, the better. My understanding is that there were a number of places where we needed to make changes in preparation for bug 637099.

Comment 13

[u279076]

(In reply to Daniel Veditz [:dveditz] from comment #4)
> Would be nice to pin down the regression range so that
>  - we're sure old branches are not affected
>  - won't accidentally infect old branches later should
>    whatever bug that caused it be backported for stability reasons

Trying to narrow down a regression range and am having inconclusive results...
Firefox Nightly 12.0a1 2012-01-01: assertion reproduced
Firefox Nightly 12.0a1 2011-12-25: no assertion
Firefox Nightly 12.0a1 2011-12-21: no assertion
Firefox Nightly 11.0a1 2011-12-20: assertion reproduced
Firefox Nightly 11.0a1 2011-12-19: no assertion

Comment 14

[Al Billings [:abillings - ex-MoCo]]

Bob, can you verify this in trunk?

Comment 15

[Bob Clary [:bc] (inactive)]

I can't reproduce any crash or assertion but the void assertion was only reproducible for a short time. I'm reluctant to call it verified since I can't reproduce on Beta/12 where it is still listed as wontfix.

fixing the component fu.

Comment 16

[u279076]

Marking this qa- given comment 15 -- I don't see how we'll be able to verify this one.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Are we going to fix this in ESR? There have been no updates in weeks and time is short.

Comment 18

[Alex Keybl [:akeybl]]

Wontfixing since bug 637099 is too risky for ESR. Please leave this bug hidden till ESR EOL.

Comment 19

[u279076]

(In reply to Alex Keybl [:akeybl] from comment #18)
> Wontfixing since bug 637099 is too risky for ESR. Please leave this bug
> hidden till ESR EOL.

Assuming you mean ESR10 EOL right? In other words, this will get automatic uplift via the train in ESR17.

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Correct.