Closed Bug 224783 Opened 22 years ago Closed 10 years ago

ASSERTION: leaking stream event: 'Not Reached'

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: timeless, Unassigned)

References

Details

(Keywords: assertion, memory-leak)

Attachments

(1 file)

Thread shutdown fix, v1
2.61 KB, patch
dcamp
: review-
Details | Diff | Splinter Review
<console output> WARNING: malformed hostname, file i:/build/mozilla/netwerk/base/src/nsURLParsers.cpp, line 625 WARNING: Should not try to set the focus on a disabled window, file i:/build/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2465 JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserLoadURL :: line 1357" data: no] Parse Time (this=034C9E48): Real time 0:0:0.40, CP time 0.040 DTD Time: Real time 0:0:0.0, CP time 0.000 Tokenize Time: Real time 0:0:0.40, CP time 0.040 Parse Time (this=034EE370): Real time 0:0:0.30, CP time 0.030 DTD Time: Real time 0:0:0.0, CP time 0.000 Tokenize Time: Real time 0:0:0.20, CP time 0.020 Reflow time (this=034355F8): Real time 0:0:0.30, CP time 0.020 Frame construction plus style resolution time (this=034355F8): Real time 0:0:0.641, CP time 0.611 Style resolution time (this=034355F8): Real time 0:0:0.661, CP time 0.641 XPC - Begin deferred Release of 1751 nsISupports pointers XPC - End deferred Releases WARNING: getting z level of unregistered window, file i:/build/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 636 WARNING: getting z level of unregistered window, file i:/build/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 636 WARNING: nsTimeoutImpl::Release() proceeding without context., file i:/build/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5175 WEBSHELL- = 3 Error loading URL https://ww.novus.net/ : 804b001e Error loading URL https://www.novus.net/ : 804b0002 ###!!! ASSERTION: event dropped because event chain is dead: 'mElderQueue', file i:/build/mozilla/xpcom/threads/nsEventQueue.cpp, line 249 Break: at file i:/build/mozilla/xpcom/threads/nsEventQueue.cpp, line 249 WARNING: PostEvent failed, file i:/build/mozilla/xpcom/io/nsStreamUtils.cpp, line 98 ###!!! ASSERTION: event dropped because event chain is dead: 'mElderQueue', file i:/build/mozilla/xpcom/threads/nsEventQueue.cpp, line 249 Break: at file i:/build/mozilla/xpcom/threads/nsEventQueue.cpp, line 249 WARNING: PostEvent failed, file i:/build/mozilla/xpcom/io/nsStreamUtils.cpp, line 98 ###!!! ASSERTION: leaking stream event: 'Not Reached', file i:/build/mozilla/xpcom/io/nsStreamUtils.cpp, line 79 Break: at file i:/build/mozilla/xpcom/io/nsStreamUtils.cpp, line 79 nsHttpTransaction::Close(unsigned int 2152398850) line 517 - this 0x034b54a8 \- mConnInfo 0x034b3958 | mRef 4 |+ mHashKey {".Swww.novus.net:443"} |+ mHost {"www.novus.net"} | mPort 443 |+ mProxyInfo {0x00000000} | mUsingHttpProxy 0 '' \ mUsingSSL 1 '' nsInputStreamReadyEvent::~nsInputStreamReadyEvent() line 79 + 22 bytes rv NS_ERROR_FAILURE SocketTra,DbgBreakPoint: NTDLL! DbgBreakPoint address 0x77f9f9df nsDebugImpl::Assertion(nsDebugImpl * const 0x03306b30, const char * 0x002e3c5c `string', const char * 0x002e3c74 `string', const char * 0x002e3c30 `string', int 79) line 276 nsDebug::Assertion(const char * 0x002e3c5c `string', const char * 0x002e3c74 `string', const char * 0x002e3c30 `string', int 79) line 109 nsInputStreamReadyEvent::~nsInputStreamReadyEvent() line 79 + 22 bytes nsInputStreamReadyEvent::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsInputStreamReadyEvent::Release(nsInputStreamReadyEvent * const 0x034b6420) line 129 + 145 bytes nsCOMPtr_base::assign_assuming_AddRef(nsISupports * 0x00000000) line 425 nsCOMPtr_base::assign_with_AddRef(nsISupports * 0x00000000) line 73 nsCOMPtr<nsIInputStreamCallback>::operator=(nsIInputStreamCallback * 0x00000000) line 565 nsPipeEvents::~nsPipeEvents() line 584 nsPipe::OnPipeException(unsigned int 2152398850, int 0) line 571 + 8 bytes nsPipeOutputStream::CloseWithStatus(nsPipeOutputStream * const 0x034b5ecc, unsigned int 2152398850) line 1045 nsHttpTransaction::Close(unsigned int 2152398850) line 517 nsHttpConnection::CloseTransaction(nsAHttpTransaction * 0x034b54a8, unsigned int 2152398850) line 457 nsHttpConnectionMgr::nsConnectionHandle::CloseTransaction(nsAHttpTransaction * 0x034b54a8, unsigned int 2152398850) line 864 nsHttpConnectionMgr::OnMsgCancelTransaction(unsigned int 2152398850, void * 0x034b54a8) line 737 nsHttpConnectionMgr::nsConnEvent::HandleEvent(PLEvent * 0x03023990) line 230 PL_HandleEvent(PLEvent * 0x03023990) line 670 + 10 bytes nsSocketTransportService::ServiceEventQ() line 351 + 9 bytes nsSocketTransportService::Run(nsSocketTransportService * const 0x00c4ccb8) line 568 + 11 bytes nsThread::Main(void * 0x00c4d5a8) line 127 + 26 bytes _PR_NativeRunThread(void * 0x00c4d6d8) line 433 + 13 bytes MSVCRTD! beginthreadex + 307 bytes KERNEL32! CreateFileA + 283 bytes xpcomhost,SearchTable: SearchTable(JSDHashTable * 0x0205fe50, const void * 0x0012951c, unsigned long 35354788, int 2) line 354 + 1 byte JS_DHashTableOperate(JSDHashTable * 0x0205fe50, const void * 0x0012951c, int 2) line 556 + 21 bytes StopResolving(JSContext * 0x02067ea0, JSResolvingKey * 0x0012951c, unsigned long 1, JSResolvingEntry * 0x0205feb8, unsigned long 0) line 1182 + 15 bytes _js_LookupProperty(JSContext * 0x02067ea0, JSObject * 0x0218fe28, long 34317192, JSObject * * 0x001295d8, JSProperty * * 0x001295cc, const char * 0x00ea2de0, unsigned int 2587) line 2456 + 23 bytes js_GetProperty(JSContext * 0x02067ea0, JSObject * 0x0218fe28, long 34317192, long * 0x00129d0c) line 2587 + 35 bytes js_Interpret(JSContext * 0x02067ea0, long * 0x00129eac) line 2763 + 1795 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 4, unsigned int 2) line 929 + 13 bytes nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x03172a80, nsXPCWrappedJS * 0x03163900, unsigned short 3, const nsXPTMethodInfo * 0x03148108, nsXPTCMiniVariant * 0x0012a23c) line 1331 + 22 bytes nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x03163900, unsigned short 3, const nsXPTMethodInfo * 0x03148108, nsXPTCMiniVariant * 0x0012a23c) line 429 PrepareAndDispatch(nsXPTCStubBase * 0x03163900, unsigned int 3, unsigned int * 0x0012a2ec, unsigned int * 0x0012a2dc) line 117 + 31 bytes SharedStub() line 147 nsBrowserStatusFilter::OnStateChange(nsBrowserStatusFilter * const 0x03172074, nsIWebProgress * 0x0291b8dc, nsIRequest * 0x03198948, unsigned int 458753, unsigned int 0) line 179 + 51 bytes nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x0291b8dc, nsIRequest * 0x03198948, int 458753, unsigned int 0) line 1224 nsDocLoaderImpl::doStartDocumentLoad() line 790 nsDocLoaderImpl::OnStartRequest(nsDocLoaderImpl * const 0x0291b8cc, nsIRequest * 0x03198948, nsISupports * 0x00000000) line 542 nsLoadGroup::AddRequest(nsLoadGroup * const 0x02946840, nsIRequest * 0x03198948, nsISupports * 0x00000000) line 620 + 31 bytes nsHttpChannel::AsyncOpen(nsHttpChannel * const 0x03198948, nsIStreamListener * 0x035298b0, nsISupports * 0x00000000) line 2750 nsDocumentOpenInfo::Open(nsIChannel * 0x03198948) line 214 + 18 bytes nsURILoader::OpenURI(nsURILoader * const 0x00c8d2b0, nsIChannel * 0x03198948, int 0, nsISupports * 0x02a311b8) line 709 + 19 bytes nsDocShell::DoChannelLoad(nsIChannel * 0x03198948, nsIURILoader * 0x00c8d2b0) line 5711 + 39 bytes nsDocShell::DoURILoad(nsIURI * 0x031a6848, nsIURI * 0x00000000, nsISupports * 0x02aefc48, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 1, nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 5484 + 38 bytes nsDocShell::InternalLoad(nsDocShell * const 0x02a311b8, nsIURI * 0x031a6848, nsIURI * 0x00000000, nsISupports * 0x00000000, int 1, const unsigned short * 0x0310cf90, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned int 1, nsISHEntry * 0x00000000, int 1, nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 5273 + 55 bytes nsDocShell::LoadURI(nsDocShell * const 0x02a311b8, nsIURI * 0x031a6848, nsIDocShellLoadInfo * 0x031b7550, unsigned int 0, int 1) line 737 + 82 bytes nsDocShell::LoadURI(nsDocShell * const 0x02a311c8, const unsigned short * 0x0325cca0, unsigned int 0, nsIURI * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) line 2492 + 38 bytes XPTC_InvokeByIndex(nsISupports * 0x02a311c8, unsigned int 8, unsigned int 5, nsXPTCVariant * 0x0012ae88) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2023 + 42 bytes XPC_WN_CallMethod(JSContext * 0x02067ea0, JSObject * 0x0218ff70, unsigned int 5, long * 0x031b451c, long * 0x0012b140) line 1269 + 14 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 5, unsigned int 0) line 912 + 23 bytes js_Interpret(JSContext * 0x02067ea0, long * 0x0012ba74) line 2933 + 15 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 2, unsigned int 0) line 929 + 13 bytes js_Interpret(JSContext * 0x02067ea0, long * 0x0012c358) line 2933 + 15 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 1, unsigned int 0) line 929 + 13 bytes js_Interpret(JSContext * 0x02067ea0, long * 0x0012cc3c) line 2933 + 15 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 2, unsigned int 6) line 929 + 13 bytes fun_apply(JSContext * 0x02067ea0, JSObject * 0x02db2d58, unsigned int 2, long * 0x031b422c, long * 0x0012cd78) line 1569 + 15 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 2, unsigned int 0) line 912 + 23 bytes js_Interpret(JSContext * 0x02067ea0, long * 0x0012d6ac) line 2933 + 15 bytes js_Invoke(JSContext * 0x02067ea0, unsigned int 1, unsigned int 2) line 929 + 13 bytes js_InternalInvoke(JSContext * 0x02067ea0, JSObject * 0x02db2d58, long 34943672, unsigned int 0, unsigned int 1, long * 0x0012d904, long * 0x0012d7d4) line 1006 + 20 bytes JS_CallFunctionValue(JSContext * 0x02067ea0, JSObject * 0x02db2d58, long 34943672, unsigned int 1, long * 0x0012d904, long * 0x0012d7d4) line 3572 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x02067e28, void * 0x02db2d58, void * 0x021532b8, unsigned int 1, void * 0x0012d904, int * 0x0012d908, int 0) line 1297 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x0318bad0, nsIDOMEvent * 0x03305ed8) line 180 + 77 bytes nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver * 0x03305f78, nsIDOMEvent * 0x03305ed8) line 462 nsXBLKeyEventHandler::HandleEvent(nsXBLKeyEventHandler * const 0x02f09400, nsIDOMEvent * 0x03305ed8) line 147 nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02f095a0, nsIDOMEvent * 0x03305ed8, nsIDOMEventTarget * 0x03305f78, unsigned int 4, unsigned int 4) line 1422 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x028dd7d8, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x0012f064, nsIDOMEventTarget * 0x03305f78, unsigned int 4, nsEventStatus * 0x0012f5f4) line 1515 + 56 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x028dd760, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x0012f064, unsigned int 4, nsEventStatus * 0x0012f5f4) line 3168 nsXULElement::HandleDOMEvent(nsXULElement * const 0x02f51b28, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x0012f064, unsigned int 4, nsEventStatus * 0x0012f5f4) line 3148 nsXULElement::HandleDOMEvent(nsXULElement * const 0x02f51ba0, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x0012f064, unsigned int 4, nsEventStatus * 0x0012f5f4) line 3148 nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x02eefcd8, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x0012f064, unsigned int 7, nsEventStatus * 0x0012f5f4) line 1953 nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x02eefcd8, nsIPresContext * 0x02815338, nsEvent * 0x0012f7c8, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f5f4) line 1432 + 29 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f7c8, nsIView * 0x0281c2b8, unsigned int 1, nsEventStatus * 0x0012f5f4) line 6192 + 47 bytes PresShell::HandleEvent(PresShell * const 0x0284a040, nsIView * 0x0281c2b8, nsGUIEvent * 0x0012f7c8, nsEventStatus * 0x0012f5f4, int 1, int & 1) line 6079 + 25 bytes nsViewManager::HandleEvent(nsView * 0x0281c2b8, nsGUIEvent * 0x0012f7c8, int 0) line 2255 nsView::HandleEvent(nsViewManager * 0x0281c0d8, nsGUIEvent * 0x0012f7c8, int 0) line 298 nsViewManager::DispatchEvent(nsViewManager * const 0x0281c0d8, nsGUIEvent * 0x0012f7c8, nsEventStatus * 0x0012f738) line 2038 + 23 bytes HandleEvent(nsGUIEvent * 0x0012f7c8) line 79 nsWindow::DispatchEvent(nsWindow * const 0x0281c364, nsGUIEvent * 0x0012f7c8, nsEventStatus & nsEventStatus_eIgnore) line 1049 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f7c8) line 1070 nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 13, long 0) line 2916 + 15 bytes nsWindow::OnChar(unsigned int 13, unsigned int 13, unsigned char 0) line 3103 nsWindow::ProcessMessage(unsigned int 258, unsigned int 13, long 1835009, long * 0x0012fc34) line 3811 + 41 bytes nsWindow::WindowProc(HWND__ * 0x00070228, unsigned int 258, unsigned int 13, long 1835009) line 1332 + 27 bytes USER32! SetTimer + 1077 bytes USER32! DispatchMessageW + 278 bytes USER32! DispatchMessageW + 11 bytes nsAppShellService::Run(nsAppShellService * const 0x00c62c70) line 476 main1(int 3, char * * 0x004442f0, nsISupports * 0x00baba78) line 1292 + 32 bytes main(int 3, char * * 0x004442f0) line 1679 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! SetUnhandledExceptionFilter + 92 bytes
Blocks: 160540
Assignee: darin → nobody
QA Contact: benc → networking
we trigger this assert pretty frequently at WINNT 5.2 fxdbug-win32-tb Dep Debug + Leak Test which makes the box orange
The first time I see this assert on WINNT 5.2 fxdbug-win32-tb Depend Debug + Leak Test on 2008/01/16 21:23:00 I went back one week till 2008-01-09 and it never occured before. After this the assert has a daily occurence.
Flags: blocking1.9?
Here's the box output: WARNING: An event was posted to a thread that will never run it (rejected): file e:/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/xpcom/threads/nsThread.cpp, line 359 WARNING: PostEvent failed: file e:/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/xpcom/io/nsStreamUtils.cpp, line 179 WARNING: An event was posted to a thread that will never run it (rejected): file e:/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/xpcom/threads/nsThread.cpp, line 359 WARNING: PostEvent failed: file e:/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/xpcom/io/nsStreamUtils.cpp, line 179 ###!!! ASSERTION: leaking stream event: 'Not Reached', file e:/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/xpcom/io/nsStreamUtils.cpp, line 163 xpcom_core!nsOutputStreamReadyEvent::`scalar deleting destructor'+0x000000000000000F (h�Z�, line 34925976) xpcom_core!nsOutputStreamReadyEvent::Release+0x000000000000008E (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nsstreamutils.cpp, line 203) xpcom_core!nsCOMPtr<nsIOutputStreamCallback>::assign_assuming_AddRef+0x0000000000000059 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\obj-fx-trunk\dist\include\xpcom\nscomptr.h, line 569) xpcom_core!nsCOMPtr<nsIOutputStreamCallback>::assign_with_AddRef+0x0000000000000027 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\obj-fx-trunk\dist\include\xpcom\nscomptr.h, line 1268) xpcom_core!nsCOMPtr<nsIOutputStreamCallback>::operator=+0x0000000000000013 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\obj-fx-trunk\dist\include\xpcom\nscomptr.h, line 714) xpcom_core!nsPipeEvents::~nsPipeEvents+0x0000000000000098 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nspipe3.cpp, line 619) xpcom_core!nsPipe::AdvanceReadCursor+0x0000000000000276 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nspipe3.cpp, line 476) xpcom_core!nsPipeInputStream::ReadSegments+0x00000000000001C7 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nspipe3.cpp, line 819) xpcom_core!nsPipeInputStream::Read+0x0000000000000022 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nspipe3.cpp, line 828) xpcom_core!nsInputStreamTee::Read+0x0000000000000063 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nsinputstreamtee.cpp, line 138) xpcom_core!NS_ConsumeStream+0x00000000000000C9 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nsstreamutils.cpp, line 578) tkitcmps!nsUrlClassifierStreamUpdater::OnDataAvailable+0x000000000000028A (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\toolkit\components\url-classifier\src\nsurlclassifierstreamupdater.cpp, line 397) necko!nsStreamListenerTee::OnDataAvailable+0x00000000000001F0 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nsstreamlistenertee.cpp, line 97) necko!nsHttpChannel::OnDataAvailable+0x0000000000000259 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp, line 4491) necko!nsInputStreamPump::OnStateTransfer+0x000000000000023D (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nsinputstreampump.cpp, line 508) necko!nsInputStreamPump::OnInputStreamReady+0x0000000000000080 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nsinputstreampump.cpp, line 398) xpcom_core!nsInputStreamReadyEvent::Run+0x000000000000004A (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\io\nsstreamutils.cpp, line 112) xpcom_core!nsThread::ProcessNextEvent+0x00000000000001FA (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\threads\nsthread.cpp, line 511) xpcom_core!NS_ProcessNextEvent_P+0x0000000000000053 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\obj-fx-trunk\xpcom\build\nsthreadutils.cpp, line 227) xpcom_core!nsThread::Shutdown+0x0000000000000141 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\threads\nsthread.cpp, line 465) necko!nsSocketTransportService::Shutdown+0x00000000000000D3 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nssockettransportservice2.cpp, line 444) necko!nsIOService::SetOffline+0x000000000000010F (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nsioservice.cpp, line 617) necko!nsIOService::Observe+0x00000000000000B3 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\netwerk\base\src\nsioservice.cpp, line 775) xpcom_core!nsObserverList::NotifyObservers+0x0000000000000065 (e:\builds\tinderbox\fx-trunk-memtest\winnt_5.2_depend\mozilla\xpcom\ds\nsobserverlist.cpp, line 129) xpcom_core!nsObserverService::NotifyObservers+0x00000000000000DF (e:\builds\tinderbox\fx-trunk-mensDOMNodeAllocator leaked 108392 bytes
My best guess for the checkin that started this would be bug 404726, but I'm not sure if that's right. It looks like we're going offline at shutdown and that shuts down nsSocketTransportService, and while that spins its thread event loop we send an OnDataAvailable to the nsUrlClassifierStreamUpdater, which consumes data from that stream, which happens to be implemented as a pipe, so we try to notify the pipe writer that there's available space in the pipe. But the thread at the other end of that pipe has stopped accepting events because its event loop has finished (I can't tell what thread this is), so we can't dispatch our notification event. So then we hit this code in ~nsInputStreamReadyEvent: // whoa!! looks like we never posted this event. take care to // release mCallback on the correct thread. if mTarget lives on the // calling thread, then we are ok. otherwise, we have to try to // proxy the Release over the right thread. if that thread is dead, // then there's nothing we can do... better to leak than crash. Since the mTarget thread is basically dead, there is of course no way to release the callback on that thread, so we leak. I'm not sure how to fix this, but it seems to me that the thread on the writing side of the pipe should close its end of the pipe somehow before it shuts down so that its callback is freed at that time, and when we read from the pipe we don't try to notify the other end.
does attachment 301575 [details] [diff] [review] from bug 412207 comment 20 help? (I haven't had an i: drive in years, so I'm not really in a position to do testing, this is merely from watching other bugs)
Given this makes the box orange I'd like to try and fix...
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → honzab
Is there some simple way to reproduce this? I presume there is some test for this.
Status: NEW → ASSIGNED
Flags: tracking1.9+ → wanted-next+
IMHO the url classifier thread is being shutdown too soon. Network thread is shutdown in "xpcom-shutdown" but the classifier worker thread has already been shutdown in "profile-before-change", what is much sooner. There are left events posted to the worker thread because all the channels' work is asynchronous even the updater's channel has been closed before the thread died. Solution could be to close the url classifier channel in "profile-before-change" or "xpcom-shutdown-threads" as it is now and shutdown the thread in "xpcom-shutdown". We must ensure that nsUrlClassifierDBService is registered as observer to "xpcom-shutdown" after the IOService. Hack but probably working to solve this bug. Opinions?
Opps, mistake: "xpcom-shutdown-threads" come intelligently after "xpcom-shutdown". I will submit a patch according to it.
URL classifier worker thread shutdown moved to "xpcom-shutdown-threads". This should prevent leakage of events posted to that thread during shutdown.
Attachment #330607 - Flags: review?(vladimir)
You really want campd to review this, not me.
Comment on attachment 330607 [details] [diff] [review] Thread shutdown fix, v1 Thanks.
Attachment #330607 - Flags: review?(vladimir) → review?(dcamp)
Comment on attachment 330607 [details] [diff] [review] Thread shutdown fix, v1 I don't think this patch will actually work around the problem. As mentioned in comment #4, the problem is in the communication between nsUrlClassifierStreamUpdater on the main thread and the thread pushing data into the pipe. The url-classifier helper thread shouldn't be involved at this point. This patch also breaks profile-before-change. By the time we're done with profile-before-change, we should be done writing to the urlclassifier3.sqlite file in that profile. In profile-before-change we need to make sure that we wait for the thread to finish processing events (including the final shutdown event) before we know we're done with the profile. Given that we protect against posting new events to the thread (all of the nsUrlClassifierDBService.cpp methods check that gDbBackgroundThread is non-null before trying to post events), I don't think we need to keep the thread around longer than we currently do.
Attachment #330607 - Flags: review?(dcamp) → review-
Bug 434559 is similar to this. Dupe-ify?
Is this still an issue?
Assignee: honzab → nobody
Blocks: 469514, 434559
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: