Apache OpenOffice (AOO) Bugzilla – Issue 18349
zombie threads when connecting to a Mozilla Address Book
Last modified: 2008-05-16 03:30:03 UTC
When you connect to a mozilla address book, it seems there are zombie threads left over. To reproduce * start a non-product build of OpenOffice.org in the debugger * go to Tools|Data Sources * create a new data source of type "Address Book/Mozilla" * break into the debugger. Notice the number of threads which are active * continue from the debugger. * For the just created data source, switch to the Tables tab page. This will open a connection for the address book. * close the dialog. This will also close the connection. * break into the debugger. => Notice the threads. There are at least 3 threads which seem to be locked, and which are related to Mozilla components. The stacks: 1. 7ffe0304() user32.dll!CreateWindowExA() + 0x27b7 necko.dll!NSGetModule() + 0x2aa99 xpcom.dll!nsComponentManager::EnumerateContractIDs() + 0x116 nspr4.dll!PRP_TryLock() + 0xa1b msvcrt.dll!_endthreadex() + 0xa0 kernel32.dll!OpenConsoleW() + 0xb8 2. 7ffe0304() ntdll.dll!NtWaitForSingleObject() + 0xc mswsock.dll!71a520a4() ws2_32.dll!select() + 0xa0 nspr4.dll!_PR_MD_UNLOCK() + 0x1eb6 nspr4.dll!PR_Poll() + 0x14 necko.dll!NSGetModule() + 0xc886 xpcom.dll!nsComponentManager::EnumerateContractIDs() + 0x116 nspr4.dll!PRP_TryLock() + 0xa1b msvcrt.dll!_endthreadex() + 0xa0 kernel32.dll!OpenConsoleW() + 0xb8 3. 7ffe0304() ntdll.dll!NtWaitForSingleObject() + 0xc kernel32.dll!WaitForSingleObject() + 0xf nspr4.dll!_PR_GetPrimordialCPU() + 0x199 nspr4.dll!PR_WaitCondVar() + 0x35 xpcom.dll!nsSlidingString::`vbase destructor'() + 0xd81 xpcom.dll!nsComponentManager::EnumerateContractIDs() + 0x116 nspr4.dll!PRP_TryLock() + 0xa1b msvcrt.dll!_endthreadex() + 0xa0 kernel32.dll!OpenConsoleW() + 0xb8 There is a forth thread which looks suspucious: 4. 7ffe0304() ntdll.dll!NtWaitForMultipleObjects() + 0xc kernel32.dll!WaitForMultipleObjects() + 0x17 kernel32.dll!OpenConsoleW() + 0xb8 The debugger claims that the execution here is in a method named "WABOpen" (unfortunately you do not see this on the stack), so this sounds to me like if it's AB-related, too. Thread 1 seems to try to open a window - which definately is a bad idea for Mozilla components embedded into OpenOffice.org. Thread 2 seems to wait for thread 1. Thread 3 perhaps also waits for thread 1. Not sure about thread 4. We should investigate this, and see what's going on here. Perhaps this is related to the overall threading issues we have with our integration, as also described in issue 6883.
adding dependency to ABI meta bug
targeting to 2.0
There are three thread mozab will always create: 1.Startup the memory manager {,mozilla\xpcom\build\nsXPComInit.cpp,} .332 2.Create the transport thread... {,mozilla\netwerk\base\src\nsSocketTransportService.cpp,} .202 3.create DNS thread {,mozilla\netwerk\dns\src\nsDnsService.cpp,} .1013 Because you say it execution a method named "WABOpen", So I guest you are working with outlook express,if so this is the last thread: 4.nsAbOutlookDirectory::DoQuery {,mozilla\mailnews\addrbook\src\nsAbOutlookDirectory.cpp,} .979 So if ignore >Thread 1 seems to try to open a window. There are nothing wrong. >Perhaps this is related to the overall threading issues we >have with our integration, as also described in issue 6883. The last one is.
But how are the three threads you mentioned related to the 3 "zombie" threads I originally described? Are they really the same? They stacks don't look to me like this. > Because you say it execution a method named "WABOpen" > So I guest you are working with outlook express Funnily, I don't. I am trying to actually access a Mozilla Address Book. > So if ignore >> Thread 1 seems to try to open a window. > There are nothing wrong. Not sure if I understand you here. Are you saying that there *is* a problem with thread1 1., or that there is *no* problem with thread 1? > The last one is. Sorry, I don't understand you here.
>But how are the three threads you mentioned related to the 3 >"zombie" threads I originally described? Mozab will always create these three threads,if you only access mozilla address book.If you access op,oe or ldap,mozab will create more threads.So I think they are the threads you described. Or maybe they the last three threads,because you have a original threads,so there are 4 threads.But I don't know who is who. > So if ignore >> Thread 1 seems to try to open a window. > There are nothing wrong. I say There *is* a problem with thread1 1.Thread 1 create a window.See http://lxr.mozilla.org/mozilla1.0/ident?i=CreateWindow.I believe http://lxr.mozilla.org/mozilla1.0/source/xpcom/threads/plevent.c#1401 is the right one.It create a window to receive thread event message.This window is a part of xpcom thread proxy art. > The last one is. I mean the last thread I described is related to the overall threading issues we have with our integration, as also described in issue 6883. OE,OP and LDAP all will create new threads.
thanks for the explanations :) If I see this right, every attempt to create an event queue in Mozilla causes a window to be created - which will lock if there is no application event loop. Sounds like exactly what Michael Meeks said in issue 6883 (2003-07-28 13:08). "Thread events won't get processed if you don't spin up an appshell and then use a gtk-based mainloop". Sounds like a bigger problem to me. I assume that as long as Mozilla code relies on event loops (and it *does*, e.g. with proxy objects), but we do *not* care for Mozilla related events in our VCL application event loop, there will be a problem.
Created attachment 8871 [details] A simple multi threads app using xpcom proxy manager
About proxytest: How to build: 1.Unzip to mozilla src dir.There are four files: <mozdir>\ProxyTest\SpeekerListener\Makefile <mozdir>\ProxyTest\SpeekerListener\Makefile.in <mozdir>\ProxyTest\SpeekerListener\nsITestProxyListener.idl <mozdir>\ProxyTest\SpeekerListener\SpeekerListener.cpp 2.Build mozilla (if never build before) 3.cd <mozdir>\ProxyTest\SpeekerListener make <enter> 4.run <mozdir>\dist\bin\SpeekerListener.exe [threads count(default 2)] You will get a out like this: Proxy Handle Thread:16660896 Creating EventQueue... Verifing calling Proxy on eventQ thread. End of Verification calling Proxy on eventQ thread. Looping for events. Spawn Threads: Thread (0) spawned,Thread:16621296 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Thread (2) spawned,Thread:16571768 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 All Threads Spawned. Wait for threads. Thread (0) Join... Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16621296, Excuter:16823312, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Thread (0) Joined. (error: 0). Thread (1) Join... Thread (1) Joined. (error: 0). Thread (2) Join... Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Creater:16571768, Excuter:16572096, Current:16660896 Thread (2) Joined. (error: 0). Thread (3) Join... Thread (3) Joined. (error: 0). Closing down Event Queue. End looping for events. Calling Cleanup. Return zero. ----------------------------------------------------------- What are they? Creater:the thread who create the object, Excuter:the thread who start the function, Current:the thread which the function code run in You can see xpcom serialize all*proxyed* code in the eventloop thread.
Created attachment 8920 [details] This time I make it threadsafe,but we need a patch to mozilla
About ProxyTest2.zip I create a thread in main(),and init xpcom/shutdown xpcom here.So this new thread is the xpcom's main thread,NS_UI_THREAD.This thread also do the main event loop.This time there does not exist the threadsafe popup window. But it there will be another issue.The event loop thread will be shutdown twice.This is because NS_ShutdownXPCOM shutdown the thread before it exit.See http://lxr.mozilla.org/mozilla1.0/source/xpcom/threads/nsThread.cpp#431. They said "nspr doesn't seem to be calling the main thread's destructor callback, so let's help it out",but maybe it is not true.The main thread's "exit()" is called another time.So we need remove the manual thread shutdown. see http://lxr.mozilla.org/mozilla1.0/source/xpcom/build/nsXPComInit.cpp#621 We need remove nsThread::Shutdown().
responsibilities changed
change subcomponent to 'none'
Migrate to a new account for security reasons.
fixed in CWS mozab04
set to fixed
Hi, I don't any threads left when closig the connection Bye Marc
This Issue is 'Verified' and not updated in 1yr+, so Closing. A Closed Issue is a Happy Issue (TM). Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~