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)); if(appShell) appShell->Quit(); 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.
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
Summary: Crash due to null sXPConnect probably in shutdown → Crash due to null sXPConnect in shutdown race-condition
i've tried lining stuff up w/ both 1_0_RELEASE and 1_0_BRANCH and neither worked http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/build/nsXPComInit.cpp&rev=MOZILLA_1_0_RELEASE&root=/cvsroot&mark=567#550 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsDOMClassInfo.cpp&rev=MOZILLA_1_0_RELEASE&mark=2855#2800 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
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.
any idea why shutdown is being called from InitXPCOM? #22 0x2914db17 in nsComponentManagerImpl::FreeServices (this=0x8fe8100) at /home/jesup/Test_moz/mozilla_source/mozilla/xpcom/components/nsComponentManager.cpp:1851 #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)
ignore that last comment.
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. ***
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, 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 firstname.lastname@example.org
Assignee: jst → dom_bugs
seems unlikely this would still be a problem
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.