Closed Bug 159553 Opened 22 years ago Closed 15 years ago

Crash due to null sXPConnect in shutdown race-condition

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jesup, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [wgate])

Attachments

(1 file, 1 obsolete file)

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.
Keywords: crash
Whiteboard: [wgate]
Attached file gdb backtrace (obsolete) —
Attached file 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 dom_bugs@netscape.com
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
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: