I just had a crash on quit while sitting on a wired.com page. The stack is interesting: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 libgklayout.dylib 0x0a1c00ac nsContentUtils::GetDocShellFromCaller() + 48 (nsContentUtils.cpp:888) 1 libgklayout.dylib 0x0a1d48d8 nsDOMImplementation::CreateDocument(nsAString_internal const&, nsAString_internal const&, nsIDOMDocumentType*, nsIDOMDocument**) + 832 (nsDocument.cpp:594) 2 libxmlextras.dylib 0x2399df44 nsXMLHttpRequest::OnStartRequest(nsIRequest*, nsISupports*) + 688 (nsXMLHttpRequest.cpp:1227) 3 libnecko.dylib 0x082cb2f4 nsHttpChannel::CallOnStartRequest() + 748 (nsHttpChannel.cpp:760) 4 libnecko.dylib 0x082d8684 nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) + 624 (nsHttpChannel.cpp:4010) 5 libnecko.dylib 0x082105f4 nsInputStreamPump::OnStateStart() + 280 (nsInputStreamPump.cpp:381) 6 libnecko.dylib 0x082103bc nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) + 200 (nsInputStreamPump.cpp:337) 7 libxpcom_core.dylib 0x01945dac nsInputStreamReadyEvent::EventHandler(PLEvent*) + 168 (nsStreamUtils.cpp:120) 8 libxpcom_core.dylib 0x0188c928 PL_HandleEvent + 116 (plevent.c:688) 9 libxpcom_core.dylib 0x0188c740 PL_ProcessPendingEvents + 260 (plevent.c:624) 10 libxpcom_core.dylib 0x0189001c nsEventQueueImpl::ProcessPendingEvents() + 144 (nsEventQueue.cpp:421) 11 libxpcom_core.dylib 0x01819fb0 NS_ShutdownXPCOM_P + 420 (nsXPComInit.cpp:827) 12 libxpcom.dylib 0x00d95240 NS_ShutdownXPCOM + 32 (nsXPComStub.cpp:140) 13 org.mozilla.camino 0x000e8bb0 NS_TermEmbedding + 204 (nsEmbedAPI.cpp:215) ... We're servicing PLEvents from NS_ShutdownXPCOM, and happen to catch a plevent that involves nsXMLHttpRequest::OnStartRequest.
People are calling into the layout module after it's shut down... Should revisit this after bug 316414 is fixed and see whether we still have a problem. I suspect we will not.
12 years ago
xmlhttprequest should probably be listening for some flavor of xpcomshutdown ... although that sounds strange. alternatively the input pump should listen and arrange to discard things when it's notified of shutdown.
Or going offline should fire stoprequest notifications on open HTTP channels...
Well, if we fix bug 316414 this event processing thing will happen while we still have references to the various services in nsContentUtils... So we'll be fine.
(In reply to comment #3) > Or going offline should fire stoprequest notifications on open HTTP channels... and we do...
er, "it does". at least since bug 202638 was fixed, which was on 2004-08-04.
A correction to comment #7 -- the crash occurs not only under OS X 10.2.8, also under OS X 10.4.7.
> Is anyone working on this bug? See comment 1. If people want to try to spot-hack this, you could make nsXMLHttpRequest observe some sort of shutdown notification that comes _before_ XPCOM_SHUTDOWN. If we have one... But what I really wonder is whether this is a problem on trunk. I would bet it's not.
bug 380468 implies that it is still present on trunk.
Created attachment 264999 [details] [diff] [review] Hold the layout module alive while there are xmlhttprequest objects, rev. 1
Comment on attachment 264999 [details] [diff] [review] Hold the layout module alive while there are xmlhttprequest objects, rev. 1 r+sr=dbaron
Fixed on trunk. Might be worth putting this on the 1.8.1 branch as well.
Don't think this is a branch "blocker" but we'll look at the approval request.
Comment on attachment 264999 [details] [diff] [review] Hold the layout module alive while there are xmlhttprequest objects, rev. 1 approved for 18.104.22.168, a=dveditz for release-drivers
Fixed on MOZILLA_1_8_BRANCH