486585 - "ASSERTION: bad!" in XPCCallContext::XPCCallContext with feed in frame, gc

Status: VERIFIED FIXED

(Core :: XPConnect, defect, P4)

Description

[Jesse Ruderman]

Attachment: testcase (refers to feed on squarefree.com)

Steps:
1. Load the testcase.
2. Wait a few seconds while it reloads itself a few times.
3. Cmd+Q.

Result: near the end of shutdown, several of
###!!! ASSERTION: bad!: 'Error', file  js/src/xpconnect/src/xpccallcontext.cpp, line 88

in XPCCallContext::XPCCallContext:

    if(!stack || NS_FAILED(stack->Peek(&topJSContext)))
    {
        NS_ERROR("bad!");
        mJSContext = nsnull;
        return;
    }

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Boris Zbarsky [:bzbarsky]]

For what it's worth, the steps in comment 0 work for me.  No assertions.

That said, I see no reason the stack given here couldn't arise if the wrapped js lives long enough into shutdown (e.g. leaks).

Comment 3

[Jesse Ruderman]

I can only reproduce about 50% of the time.  I forgot to mention that in comment 0, sorry.

Is the assertion bogus or does it point to a real problem?  Or is it hard to tell without debugging?

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm not sure.  It points to an inability to actually set up an XPCCallContext properly because we're too far into shutdown.  But I'm not sure what that means in practice.

Comment 5

[Peter Van der Beken [:peterv]]

We could avoid this particular case by checking if mIdentity is an nsXPCWrappedJS, but not sure we want to do that for every call to FlatJSObjectFinalized.

Comment 7

[Peter Van der Beken [:peterv]]

BTW, nothing bad happens after the assertion AFAICT, because we check if the XPCCallContext is valid.

Comment 8

[Andreas Gal :gal]

Test disabled in TM tre until this is fixed.

http://hg.mozilla.org/tracemonkey/rev/1d2bb1304fe4

Comment 9

[Peter Van der Beken [:peterv]]

Attachment: v1

I added the assertion to SetCallInfo and SetIDispatchInfo because they set mState and we want to know if somebody clobbers INIT_FAILED/SYSTEM_SHUTDOWN.

Comment 10

[Peter Van der Beken [:peterv]]

I also reenabled test_urlformatter.js on trunk.

Comment 11

[Aakash Desai [:aakashd]]

verified FIXED on debug builds using the attached testcase (no assertions):

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre)
Gecko/20090608 Shiretoko/3.5pre ID:20090608122057

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090608 Minefield/3.6a1pre ID:20090608122028

Comment 12

[Aakash Desai [:aakashd]]

Just for dotting the I's (so to speak):

pushed: http://hg.mozilla.org/mozilla-central/rev/76e5019b7ff4

and

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/23363f342a9c