Crash due to null sXPConnect in shutdown race-condition




DOM: Core & HTML
16 years ago
9 years ago


(Reporter: jesup, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [wgate])


(1 attachment, 1 obsolete attachment)



16 years ago
This is being hit in a variant based on 1.0 release.

We're crashing due to a null sXPConnect in nsWindowSH::GetProperty. 
nsDOMClassInfo::Shutdown has already been called, which is why sXPConnect is
null. I can tell this because sIsInitialized is true (Shutdown doesn't set it
back to false) and everything else matches (id set back to 0, etc).  I can't
think of any changes we've made that would affect any of this other than we have
a private protocol handler which will force a shutdown:

In the handler's NewChannel method we do:

nsCOMPtr<nsIAppShellService> appShell(do_GetService(kAppShellServiceCID));

We use the imminent-shutdown observer (called from nsAppShellService::Quit();
see bugzilla bug 149764 for the patch) to do an XMLExtras post (synchronously).
So far as I can tell, it's not in imminent-shutdown here - if someone knows how
to check where in shutdown we are I'm more than willing to look through the core
file or add some code.

I strongly suspect this is a shutdown race condition.

I'm afraid I can't give much more info since I just harvest the corefiles from
our test machines.  I'll attach a backtrace.


16 years ago
Keywords: crash
Whiteboard: [wgate]

Comment 1

16 years ago
Created attachment 92905 [details]
gdb backtrace

Comment 2

16 years ago
Created attachment 92916 [details]
correct backtrace

Previous backtrace had xpcom messed up (did it on a different machine).  Note
that the crash came from within FreeServices in ShutdownXPCOM
Attachment #92905 - Attachment is obsolete: true


16 years ago
Summary: Crash due to null sXPConnect probably in shutdown → Crash due to null sXPConnect in shutdown race-condition

Comment 3

16 years ago
i've tried lining stuff up w/ both 1_0_RELEASE and 1_0_BRANCH and neither worked

The first marker indicates you're deep in the depths of shutdown, which iirc
means no creations allowed.

Maybe nsXPCWrappedJSClass::CallMethod should error if !sXPConnect?
Severity: normal → critical

Comment 4

16 years ago
We're apparently deep in Shutdown with a docloader still running, and we're
deleting it.  That ends up doing a FireOnStateChange() to run some JS, and since
the DOM's xpconnect pointer has been freed already we go boom.

One solution would be as you say to add a null-test.  That would help, but what
other things would need to be checked if we have docloaders still running here?
 Better would be to cancel all loads before we get to this point, I suspect, and
block any new ones.

Comment 5

16 years ago
any idea why shutdown is being called from InitXPCOM?  

#22 0x2914db17 in nsComponentManagerImpl::FreeServices (this=0x8fe8100)
#23 0x2910b781 in NS_ShutdownXPCOM (servMgr=0x0)
    at /home/jesup/Test_moz/mozilla_source/mozilla/xpcom/build/nsXPComInit.cpp:557
#24 0x834ed92 in main (argc=9, argv=0xbfbff914)

Comment 6

16 years ago
ignore that last comment.

Comment 7

16 years ago
Downgrading since it's a crash-on-shutdown bug, but it's still important (and
still generates massive core files as well as time repeatedly verifying that
this is a know mostly-innocuous bug).
Severity: critical → major
*** Bug 161445 has been marked as a duplicate of this bug. ***

Comment 9

15 years ago
By the definitions on <> and
<>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
Mass-reassigning bugs to
Assignee: jst → dom_bugs

Comment 11

12 years ago
seems unlikely this would still be a problem


10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general


9 years ago
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.