Last Comment Bug 494014 - shutdown hang, high cpu, no open imap connections
: shutdown hang, high cpu, no open imap connections
Status: RESOLVED FIXED
[no l10n impact][fixed RC2 build 1][gs]
: fixed-seamonkey2.0.1, hang, qawanted
Product: MailNews Core
Classification: Components
Component: Networking: IMAP (show other bugs)
: Trunk
: x86 Windows Vista
: P1 critical with 1 vote (vote)
: Thunderbird 3
Assigned To: David :Bienvenu
:
Mentors:
http://gsfn.us/t/n2d1
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 12:43 PDT by Wayne Mery (:wsmwk, NI for questions)
Modified: 2010-02-22 09:43 PST (History)
14 users (show)
davida: blocking‑thunderbird3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
.1-fixed


Attachments
hang from 20090612 8am (25.71 KB, text/plain)
2009-06-12 05:52 PDT, Wayne Mery (:wsmwk, NI for questions)
no flags Details
from T40 @home (31.82 KB, text/plain)
2009-07-07 06:26 PDT, Wayne Mery (:wsmwk, NI for questions)
no flags Details
don't tell the user about connection errors on shutdown - checked in. (692 bytes, patch)
2009-09-10 12:54 PDT, David :Bienvenu
standard8: review+
standard8: superreview+
Details | Diff | Review
windbg stack for hang (27.42 KB, text/plain)
2009-09-12 09:53 PDT, Wayne Mery (:wsmwk, NI for questions)
no flags Details
fix some cases of hangs - checked in. (3.68 KB, patch)
2009-09-23 13:36 PDT, David :Bienvenu
standard8: review+
standard8: superreview+
Details | Diff | Review
proposed fix (890 bytes, patch)
2009-11-30 11:12 PST, David :Bienvenu
standard8: review+
standard8: superreview+
standard8: approval‑thunderbird3+
standard8: approval‑thunderbird3.0.1+
Details | Diff | Review

Description Wayne Mery (:wsmwk, NI for questions) 2009-05-20 12:43:13 PDT
shutdown hang, high cpu, no open imap connections per netstat
normally I hang with no cpu and imap connections active
but today, two high cpu hangs
hobie
gloda is off
windows indexing is on
20090518 build on vista

(clicking threads in visual studio hangs VS with "visual studio is busy")

It may be that some failed folder operations trigger this, as I am testing bug 222485

--------------------------------------------------------------------
one of the breaks

 	thunderbird.exe!nsAppShell::ScheduleNativeEventCallback()  Line 144 + 0x12 bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnDispatchedEvent(nsIThreadInternal * thr=0x0261b2e0)  Line 237	C++
 	xpcom_core.dll!nsThread::PutEvent(nsIRunnable * event=0x02615f44)  Line 370	C++
 	xpcom_core.dll!nsThread::Dispatch(nsIRunnable * event=0x08572528, unsigned int flags=0)  Line 406 + 0xb bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x0261b2e0, int mayWait=0, unsigned int recursionDepth=0)  Line 308 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x001bfbac)  Line 501	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0261b2e0, int mayWait=1)  Line 227 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::Shutdown()  Line 465 + 0xa bytes	C++
 	xpcom_core.dll!nsThreadManager::Shutdown()  Line 144 + 0x6 bytes	C++
 	xpcom_core.dll!NS_ShutdownXPCOM_P(nsIServiceManager * servMgr=0x02662104)  Line 789	C++
 	thunderbird.exe!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 952	C++
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x0261e090, const nsXREAppData * aAppData=0x02615380)  Line 3346	C++
 	thunderbird.exe!NS_internal_main(int argc=1, char * * argv=0x0261e090)  Line 104	C++


--------------------------------------------------------------------
another, more typical break afaict

>	nspr4.dll!PR_Lock(PRLock * lock=0x02644230)  Line 325	C
 	nspr4.dll!PR_EnterMonitor(PRMonitor * mon=0x02616440)  Line 99 + 0x6 bytes	C
 	xpcom_core.dll!nsAutoMonitor::nsAutoMonitor(PRMonitor * mon=0x02616440)  Line 304 + 0x7 bytes	C++
 	xpcom_core.dll!nsEventQueue::PutEvent(nsIRunnable * runnable=0x08572528)  Line 114	C++
 	xpcom_core.dll!nsThread::nsChainedEventQueue::PutEvent(nsIRunnable * event=0x08572528)  Line 632 + 0x9 bytes	C++
 	xpcom_core.dll!nsThread::PutEvent(nsIRunnable * event=0x08572528)  Line 362 + 0xb bytes	C++
 	xpcom_core.dll!nsThread::Dispatch(nsIRunnable * event=0x08572528, unsigned int flags=0)  Line 406 + 0xb bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x0261b2e0, int mayWait=0, unsigned int recursionDepth=0)  Line 308 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x001bfbac)  Line 501	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0261b2e0, int mayWait=1)  Line 227 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::Shutdown()  Line 465 + 0xa bytes	C++
 	xpcom_core.dll!nsThreadManager::Shutdown()  Line 144 + 0x6 bytes	C++
 	xpcom_core.dll!NS_ShutdownXPCOM_P(nsIServiceManager * servMgr=0x02662104)  Line 789	C++
 	thunderbird.exe!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 952	C++
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x0261e090, const nsXREAppData * aAppData=0x02615380)  Line 3346	C++
 	thunderbird.exe!NS_internal_main(int argc=1, char * * argv=0x0261e090)  Line 104	C++
 	thunderbird.exe!wmain(int argc=39968912, wchar_t * * argv=0x0261c700)  Line 112	C++
 	thunderbird.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes	C
 	kernel32.dll!76f34911()
Comment 1 Wayne Mery (:wsmwk, NI for questions) 2009-05-21 12:38:52 PDT
another hang.  stacks via taskmanager dump (because clicking threads tab in visual studio 2005 hangs VS)


Thunderbird(3).dmp dated 20090521

------------------------------------------------------------------------------
>	nspr4.dll!_PR_MD_ATOMIC_INCREMENT(int * val=0x07157c04)  Line 1022	C
 	xpcom_core.dll!nsAtomService::AddRef()  Line 42 + 0xe bytes	C++
 	xpcom_core.dll!nsRefPtr<nsThreadStartupEvent>::nsRefPtr<nsThreadStartupEvent>(nsThreadStartupEvent * aRawPtr=0x07157c00)  Line 981	C++
 	xpcom_core.dll!nsEventQueue::PutEvent(nsIRunnable * runnable=0x07157c00)  Line 112	C++
 	xpcom_core.dll!nsThread::nsChainedEventQueue::PutEvent(nsIRunnable * event=0x07157c00)  Line 632 + 0x9 bytes	C++
 	xpcom_core.dll!nsThread::PutEvent(nsIRunnable * event=0x07157c00)  Line 362 + 0xb bytes	C++
 	xpcom_core.dll!nsThread::Dispatch(nsIRunnable * event=0x07157c00, unsigned int flags=0)  Line 406 + 0xb bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x0271b2e0, int mayWait=0, unsigned int recursionDepth=0)  Line 308 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0018f410)  Line 501	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x0271b2e0, int mayWait=1)  Line 227 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::Shutdown()  Line 465 + 0xa bytes	C++
 	xpcom_core.dll!nsThreadManager::Shutdown()  Line 144 + 0x6 bytes	C++
 	xpcom_core.dll!NS_ShutdownXPCOM_P(nsIServiceManager * servMgr=0x02762104)  Line 789	C++
 	thunderbird.exe!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 952	C++
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x0271e090, const nsXREAppData * aAppData=0x02715380)  Line 3346	C++
 	thunderbird.exe!NS_internal_main(int argc=1, char * * argv=0x0271e090)  Line 104	C++
 	thunderbird.exe!wmain(int argc=41017488, wchar_t * * argv=0x0271c700)  Line 112	C++
 	thunderbird.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

---------------------------------------------------------------------
>	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	kernel32.dll!_WaitForSingleObjectEx@12()  + 0x84 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	thunderbird.exe!google_breakpad::ExceptionHandler::ExceptionHandlerThreadMain(void * lpParameter=0x0273f0e0)  Line 279 + 0xe bytes	C++
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

---------------------------------------------------------------------
 	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	kernel32.dll!_WaitForSingleObjectEx@12()  + 0x84 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x027aabf4, _MDLock * lock=0x027a9eac, unsigned int timeout=1000)  Line 282	C
 	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x027288c0, PRCondVar * cvar=0x027aab80, PRLock * lock=0x027a9e90, unsigned int timeout=1000)  Line 205	C
 	nspr4.dll!PR_WaitCondVar(PRCondVar * cvar=0x027aab80, unsigned int timeout=1000)  Line 547 + 0xd bytes	C
 	thunderbird.exe!XPCJSRuntime::WatchdogMain(void * arg=0x027e9000)  Line 827	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x027f4b80)  Line 448	C
 	nspr4.dll!pr_root(void * arg=0x027288c0)  Line 122 + 0xd bytes	C
>	mozcrt19.dll!_callthreadstartex()  Line 348 + 0x9 bytes	C
 	mozcrt19.dll!_threadstartex(void * ptd=0x0278b400)  Line 326 + 0x5 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

---------------------------------------------------------------------
 	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	kernel32.dll!_WaitForSingleObjectEx@12()  + 0x84 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x04d6b384, _MDLock * lock=0x04d6b29c, unsigned int timeout=4294967295)  Line 282	C
 	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x05513780, PRCondVar * cvar=0x04d6b310, PRLock * lock=0x04d6b280, unsigned int timeout=4294967295)  Line 205	C
 	nspr4.dll!PR_Wait(PRMonitor * mon=0x054d6590, unsigned int ticks=4294967295)  Line 184 + 0x1a bytes	C
 	xpcom_core.dll!nsEventQueue::GetEvent(int mayWait=1, nsIRunnable * * result=0x05d4fae4)  Line 85 + 0x9 bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x05d4fb04)  Line 503	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x05512650, int mayWait=1)  Line 227 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x05512650)  Line 254 + 0x8 bytes	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x05566340)  Line 448	C
 	nspr4.dll!pr_root(void * arg=0x05513780)  Line 122 + 0xd bytes	C
>	mozcrt19.dll!_callthreadstartex()  Line 348 + 0x9 bytes	C
 	mozcrt19.dll!_threadstartex(void * ptd=0x04d3e800)  Line 326 + 0x5 bytes	C

---------------------------------------------------------------------
 	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	kernel32.dll!_WaitForSingleObjectEx@12()  + 0x84 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv=0x05ea5da4, _MDLock * lock=0x05ea5c2c, unsigned int timeout=4294967295)  Line 282	C
 	nspr4.dll!_PR_WaitCondVar(PRThread * thread=0x08575500, PRCondVar * cvar=0x05ea5d30, PRLock * lock=0x05ea5c10, unsigned int timeout=4294967295)  Line 205	C
 	nspr4.dll!PR_Wait(PRMonitor * mon=0x07cbeae0, unsigned int ticks=4294967295)  Line 184 + 0x1a bytes	C
 	xpcom_core.dll!nsPipeInputStream::Wait()  Line 653 + 0xd bytes	C++
 	xpcom_core.dll!nsPipeInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* writer=0x6de006a1, void * closure=0x07da4000, unsigned int count=24609, unsigned int * readCount=0x084ff984)  Line 779	C++
 	xpcom_core.dll!nsStorageInputStream::Read(char * aBuffer=0x07da4000, unsigned int aCount=24609, unsigned int * aNumRead=0x084ff984)  Line 425	C++
 	thunderbird.exe!nsMsgLineStreamBuffer::ReadNextLine(nsIInputStream * aInputStream=0x069d5708, unsigned int & aNumBytesInLine=0, int & aPauseForMoreData=0, unsigned int * prv=0x084ff9cc, int addLineTerminator=0)  Line 403	C++
 	thunderbird.exe!nsImapProtocol::CreateNewLineFromSocket()  Line 4592 + 0x1c bytes	C++
 	thunderbird.exe!nsImapServerResponseParser::GetNextLineForParser(char * * nextLine=0x08595960)  Line 127 + 0xe bytes	C++
 	thunderbird.exe!nsIMAPGenericParser::AdvanceToNextLine()  Line 183	C++
 	thunderbird.exe!nsIMAPGenericParser::AdvanceToNextToken()  Line 154	C++
 	thunderbird.exe!nsImapServerResponseParser::ParseIMAPServerResponse(const char * aCurrentCommand=0x084ffac0, int aIgnoreBadAndNOResponses=0, char * aGreetingWithCapability=0x00000000)  Line 236	C++
 	thunderbird.exe!nsImapProtocol::ParseIMAPandCheckForNewMail(const char * commandString=0x084ffac0, int aIgnoreBadAndNOResponses=0)  Line 1846	C++
 	thunderbird.exe!nsImapProtocol::HandleIdleResponses()  Line 1396	C++
 	thunderbird.exe!nsImapProtocol::ImapThreadMainLoop()  Line 1374	C++
 	thunderbird.exe!nsImapProtocol::Run()  Line 1056	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x084ffb7c)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00000001, int mayWait=1)  Line 227 + 0xd bytes	C++
 	xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x07d25ce0)  Line 254 + 0x8 bytes	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x07d071f0)  Line 448	C
 	nspr4.dll!pr_root(void * arg=0x08575500)  Line 122 + 0xd bytes	C
>	mozcrt19.dll!_callthreadstartex()  Line 348 + 0x9 bytes	C
 	mozcrt19.dll!_threadstartex(void * ptd=0x08599000)  Line 326 + 0x5 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

---------------------------------------------------------------------
and 2 WIN32 threads
Comment 2 Wayne Mery (:wsmwk, NI for questions) 2009-05-21 14:48:04 PDT
just noticed working set is < 1MB, so it's definitely pretty much shut down.
Comment 3 Wayne Mery (:wsmwk, NI for questions) 2009-05-26 04:45:08 PDT
(In reply to comment #31)
> hung with my only shutdown today using the tryserver build

The patch in bienvenu's 2009-05-21 tryserver build for bug 487965 did not help here - I just hung with high cpu (vista laptop home)
Comment 4 Wayne Mery (:wsmwk, NI for questions) 2009-06-11 04:33:08 PDT
I just reproduced this with Bug 497059's tryserver TB 3.0b 090610 bienvenu shutdown

hopefully will have stacks later today
Comment 5 Wayne Mery (:wsmwk, NI for questions) 2009-06-12 05:52:54 PDT
Created attachment 382950 [details]
hang from 20090612 8am

bienvenu, sorry, this is the best I can do on this one. 20090611 build.

loading in windbg seems to be having trouble with symbols. Example - 
 *** WARNING: Unable to verify checksum for C:\Program Files\mozilla.org\TB 3.0b 090611\thunderbird.exe
Comment 6 Wayne Mery (:wsmwk, NI for questions) 2009-07-07 06:26:44 PDT
Created attachment 387186 [details]
from T40 @home

20090704 nightly build.
nothing unusual about the shutdown, except I think indexing was in progress
Comment 7 Gary Kwong [:gkw] [:nth10sd] 2009-07-10 05:39:45 PDT
(In reply to comment #6)
> Created an attachment (id=387186) [details]
> from T40 @home
> 
> 20090704 nightly build.
> nothing unusual about the shutdown, except I think indexing was in progress

Looking at the hang stack, it seems threads 5 and 6 are blocking each other - bienvenu, am I correct?
Comment 8 David :Bienvenu 2009-07-10 08:30:36 PDT
no, they're both waiting for the same kind of thing, which means neither of them have it. I believe necko/gecko has shutdown sufficiently that the imap thread io is blocking, e.g., timeouts don't work, and we're not going to get any data. I don't know why we haven't managed to kill the channel, etc, to stop this from happening.
Comment 9 Wayne Mery (:wsmwk, NI for questions) 2009-07-28 13:53:10 PDT
FTR, just happened, XP, 0722 build (but haven't seen it much lately)
Comment 10 Mark Banner (:standard8) 2009-08-25 03:24:48 PDT
This feels like we should attack it in b4 if we can find the cause.
Comment 11 David :Bienvenu 2009-08-25 09:28:22 PDT
taking
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2009-09-01 10:50:38 PDT
bleh, can't reproduce on demand now with 8/31 builds.  Will try at home tonight after hike with Gary
Comment 13 David :Bienvenu 2009-09-08 08:11:55 PDT
I'm leaving this open for now to see if I can reproduce the issue standard8 saw where starting up and shutting down w/o a network connection produced the hang with high cpu.
Comment 14 Wayne Mery (:wsmwk, NI for questions) 2009-09-08 13:22:35 PDT
shutdown hang with 20090903 build xp@work, but that's precheckin from bug 497059. 20090908, one restart, no hang. but bears more testing than I can do right now.
Comment 15 David :Bienvenu 2009-09-09 15:34:06 PDT
I tried Standard8's scenario - I didn't see a hang on shutdown, but I did see a few alerts about being unable to connect to the mail server that appeared after I did a file | exit. I wonder if Standard8 saw alert(s) for the account(s) configured to check mail on startup before trying to exit or not. I think we could skip showing those alerts if we're in the process of shutting down.
Comment 16 Wayne Mery (:wsmwk, NI for questions) 2009-09-09 19:38:20 PDT
20090909 hung tonight on vista
Comment 17 David :Bienvenu 2009-09-10 12:49:27 PDT
I've been playing around with shutting down with my dsl modem disconnected - I haven't seen any hangs yet...Wayne, do you empty trash or expunge inbox on shutdown for any of your imap accounts?

I've also tried kicking off a compact folders and doing an immediate file | exit. That hasn't caused any problems yet either.
Comment 18 David :Bienvenu 2009-09-10 12:54:22 PDT
Created attachment 399804 [details] [diff] [review]
don't tell the user about connection errors on shutdown - checked in.

I don't know if this will help, but it seems like a reasonable thing to do.  This only prevents alert messages that we generate, like connection errors, not alerts/errors the server passes along to us, which we probably also want to suppress at some point.
Comment 19 David :Bienvenu 2009-09-10 16:59:56 PDT
I just encountered a hang on shutdown - the cause turned out to be closing nntp connections on shutdown, from the offline notification. There was a js listener that hung.  I had subscribed to a few new newsgroups, and read some messages in the session. We should have closed the nntp connections earlier, in the quit-application-granted notification, like we do for imap, so I'll check into why that didn't happen.
Comment 20 Mark Banner (:standard8) 2009-09-11 06:24:30 PDT
Comment on attachment 399804 [details] [diff] [review]
don't tell the user about connection errors on shutdown - checked in.

Yeah this should help if we're hitting this case anywhere.
Comment 21 David :Bienvenu 2009-09-11 10:01:02 PDT
One thing I've noticed is that if I've sent an e-mail in a session, shutting down takes a lot longer because we've got to cleanup the cached compose window. I *think* this makes it more likely to hang on shutdown.
Comment 22 Wayne Mery (:wsmwk, NI for questions) 2009-09-12 09:53:42 PDT
Created attachment 400288 [details]
windbg stack for hang

20090912 nightly build - d531@home
don't know why symbols are lacking. will try to reproduce with better symbols
Comment 23 David :Bienvenu 2009-09-14 10:21:20 PDT
yeah, better symbols would be very helpful.
Comment 24 David Ascher (:davida) 2009-09-17 16:26:12 PDT
AFAIK the patch in bug 497059 didn't fix it.
Comment 25 Chris Kolar 2009-09-17 22:31:17 PDT
Hi.  I see this running 3b3 as Eudora 8b7.  I turned off penolepe extension and still get consistent 40% cpu (on a dual core) after exit under XP, memory usage seems to stay stable thought I just watched it for a minute or two.  No connection artifacts under netstat.  This happens 100% of the time that I run the program and requires a process kill.
Comment 26 David :Bienvenu 2009-09-22 09:48:02 PDT
the stacks of the hang on shutdown have changed quite a bit - the imap threads are no longer blocking. At this point, it looks like the UI thread is blocking but it's hard to tell on what. I have not been able to reproduce any of the hangs, which is making fixing it a bit difficult.
Comment 27 mozilla 2009-09-23 03:38:48 PDT
I've been sent here from bug 508263, as my hangs are consistent with what's seen here.

However mine are with MacOS X.

FWIW, I'm 90% sure that all of the hangs I've seen are where I've quit Thunderbird whilst a long-lived IMAP "expunge" (aka "compact") operation is ongoing.
Comment 28 David :Bienvenu 2009-09-23 09:28:23 PDT
Ray, are you compacting all folders, or a single imap folder? I added code that prevented us from running urls after shutdown had started, but I allowed an exception for expunge urls, because the user can configure TB to expunge the inbox on shutdown. This means if you start compacting all folders and then do an immediate exit, the chaining of compact urls will continue even during shutdown. I don't see hangs when I do that, but I definitely see some bad looking assertions. I could fix the shutdown protection code to truly only allow urls that were valid at shutdown by making the shutdown code set a property on the url saying it was OK to run on shutdown...but that wouldn't help with the case of a single url that was started before you exited.
Comment 29 mozilla 2009-09-23 09:43:17 PDT
To be honest, I'm not sure whether it's generally a single folder or multiple folders.  

AFAIK the UI action is the same, and whether it's single or multiple depends simply on whether I've got messages in more than one folder tagged for deletion?

If you can confirm that I may be able to try and reproduce the problem.  I _suspect_ that it's multiple folders that's the issue.
Comment 30 David :Bienvenu 2009-09-23 09:46:35 PDT
there's a folder pane context menu that lets you compact a single folder. File | compact folders attempts to expunge every folder in your imap account. If you're doing a file | compact folders, then it's multiple folders.
Comment 31 mozilla 2009-09-23 09:56:50 PDT
Ah, right... :)

I always use a custom "Compact" button which presumably is equivalent to the "File|Compact Folders" option rather than the context menu.

I don't have "compact on exit" enabled.
Comment 32 David :Bienvenu 2009-09-23 11:16:23 PDT
the Compact button from the customize toolbar palette just compacts the current folder.
Comment 33 David :Bienvenu 2009-09-23 13:36:27 PDT
Created attachment 402431 [details] [diff] [review]
fix some cases of hangs - checked in.

This patch won't fix all the hangs, but it does cleanup some problems I was able to reproduce.

The scenario I was able to reproduce was compacting an imap folder and shutting down immediately, with some cleanup on exit prefs set (e.g., expunge inbox on exit - not many people have those set, I know). 

The first thing I noticed was that we were never getting out of the NS_ProcessPendingEvents call, presumably because we were generating so many events compacting the imap folder from the UI (in particular, it's offline store). So I added a timeout to the process pending events call. So we'll only process events for a millisecond before returning to the loop. Since we go through the loop 5000 times if needed, we should process a reasonable number of events.

The next thing I noticed was that we complete each server's cleanup before marking the next server as shutting down. This increases the chances that some other background activity can launch urls during shutdown. So I changed nsImapIncomingServer::GetImapConnectionAndLoadUrl to check the global account manager shutting down setting as opposed to the per server setting before deciding to run a url. This could only help users with multiple accounts (sorry, Bryan).

Finally, I noticed that sometimes urls still running at shutdown after we've torn down the account structure would reload the account structure. That's not something we want to do at shutdown, so I protect against that.
Comment 34 Mark Banner (:standard8) 2009-09-24 08:00:44 PDT
Comment on attachment 402431 [details] [diff] [review]
fix some cases of hangs - checked in.

>-                 NS_ProcessPendingEvents(thread);
>+                 NS_ProcessPendingEvents(thread, PR_MicrosecondsToInterval(1000UL));
...
>-                 NS_ProcessPendingEvents(thread);
>+                 NS_ProcessPendingEvents(thread, PR_MicrosecondsToInterval(1000));

I think you want UL here as well.

>+  PRBool shuttingDown;
>+  (void) accountMgr->GetShutdownInProgress(&shuttingDown);
>+  if (shuttingDown)

nit: I don't mind not checking the result, but I'd prefer shuttingDown to be initialised one way or the other - just in case someone changed something.

r/sr=Standard8 with those fixed, lets see how this helps folks.
Comment 35 David :Bienvenu 2009-09-24 08:16:47 PDT
patch checked in, with nits addressed. 

I doubt this will fix the problem clarkbw has been seeing - I'm working on reproducing that.
Comment 36 David :Bienvenu 2009-10-08 07:31:14 PDT
Now that fix for bug 420744 has landed (only affected users who used ldap autocomplete, will be in tomorrow's build), I wonder if anyone can still reproduce this.
Comment 37 mozilla 2009-10-08 08:39:42 PDT
I don't seem to be able to reproduce it anymore, but it was always somewhat intermittent.
Comment 38 Bryan Clark (DevTools PM) [@clarkbw] 2009-10-13 10:08:29 PDT
Tried to reproduce this again on Friday but couldn't make anything happen.  I'll give it another try this afternoon but it was so easy to reproduce before that I'm feeling like this has disappeared now.
Comment 39 David :Bienvenu 2009-10-14 08:29:30 PDT
OK, I'll mark this fixed - if folks still see this with recent nightlies, we'll re-evaluate.
Comment 40 David :Bienvenu 2009-11-30 11:07:23 PST
I've found a new way to reproduce this, along with a fix. If you create a profile with 2.0, add an imap account, and set it to use "tls if available" and then run 3.0 against that profile, it will hang on shutdown, if you've connected to the imap server.

Or, you can create a profile in 3.0, and using the config editor, switch the socket type for that server from 2 to 1, restart, and see the hang on shutdown on the next run. Patch upcoming.
Comment 41 David :Bienvenu 2009-11-30 11:12:14 PST
Created attachment 415186 [details] [diff] [review]
proposed fix

In the tls if available case, the first time you connect in a given tb session, we detect that the server supports TLS after connecting, and re-run the url with the knowledge that the server supports TLS, so that the second time we run the url, with a new connection, we can set up the connection correctly. The problem was that the previous connection was not shut down sufficiently, and wasn't getting cleaned up. We made enough changes to the code that cleans up imap connections that this most likely broke in 3.0.

The code that's changed only runs in the above scenario, so it only affects tls if available connections on servers that do support STARTTLS.

I have a second patch that migrates the setting to always use TLS when we detect such a server, but I think that's 3.01 fodder.
Comment 42 Mark Banner (:standard8) 2009-11-30 16:11:08 PST
Comment on attachment 415186 [details] [diff] [review]
proposed fix

r/sr/a=Standard8
Comment 43 David :Bienvenu 2009-11-30 16:28:52 PST
changeset:   4469:8babd83ca9ec
tag:         tip
user:        David Bienvenu <bienvenu@nventure.com>
date:        Mon Nov 30 16:28:07 2009 -0800
summary:     an other fix for imap hang on shutdown, with use tls if available s
et, r/sr=standard8, 494014

fixed on trunk.
Comment 44 Mark Banner (:standard8) 2009-11-30 16:50:44 PST
(In reply to comment #41)
> Created an attachment (id=415186) [details]
> proposed fix

Checked into 1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/f95a9b068715
checked into relbranch: http://hg.mozilla.org/releases/comm-1.9.1/rev/47f5c82a8c10
Comment 45 Wayne Mery (:wsmwk, NI for questions) 2009-12-01 06:48:01 PST
note, my two of my recent hangs are reported in  bug 524315
Comment 46 Peep Chaintreuil 2009-12-03 16:19:52 PST
I'm seeing a similar (the same?) hang in 3.0rc2.  It's 100% reproducable by by viewing any message and having enigmail enabled.

I've got a bug with that project, but they think it may be this (Thunderbird) bug.

Enigmail bug:
https://www.mozdev.org/bugs/show_bug.cgi?id=22072
Comment 47 David :Bienvenu 2009-12-03 16:34:26 PST
All bets are off with Enigmail as far as core Thunderbird is concerned. If you turn off enigmail (e.g., start in safe mode), and the bug doesn't happen, then it's an enigmail problem.
Comment 48 Chris Kolar 2010-01-06 11:47:23 PST
Followup to my comment #25 above, the new Eudora drop 8b8 using Thunderbird 3b4 is still showing this behavior.  I don't know if that is a recent enough TB build to incorporate the above fixes, but I wanted its presence in the new Eudora drop to be noted.
Comment 49 Wayne Mery (:wsmwk, NI for questions) 2010-01-10 17:15:54 PST
Chris, the patch for this isn't in TB3b4 (circa september 15), so Eudora 8b8 wouldn't have it.
Comment 50 Wayne Mery (:wsmwk, NI for questions) 2010-02-22 09:43:58 PST
link up to http://gsfn.us/t/n2d1 report

Note You need to log in before you can comment on or make changes to this bug.