494014 - shutdown hang, high cpu, no open imap connections

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect, P1)

Description

[Wayne Mery (:wsmwk)]

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)]

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)]

just noticed working set is < 1MB, so it's definitely pretty much shut down.

Comment 3

[Wayne Mery (:wsmwk)]

(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)]

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)]

Attachment: 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)]

Attachment: from T40 @home

20090704 nightly build.
nothing unusual about the shutdown, except I think indexing was in progress

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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]

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)]

FTR, just happened, XP, 0722 build (but haven't seen it much lately)

Comment 10

[Mark Banner (:standard8)]

This feels like we should attack it in b4 if we can find the cause.

Comment 11

[David :Bienvenu]

taking

Comment 12

[Wayne Mery (:wsmwk)]

bleh, can't reproduce on demand now with 8/31 builds.  Will try at home tonight after hike with Gary

Comment 13

[David :Bienvenu]

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)]

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]

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)]

20090909 hung tonight on vista

Comment 17

[David :Bienvenu]

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]

Attachment: 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]

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)]

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]

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)]

Attachment: 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]

yeah, better symbols would be very helpful.

Comment 24

[David Ascher (:davida)]

AFAIK the patch in bug 497059 didn't fix it.

Comment 25

[Chris Kolar]

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]

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]

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]

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]

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]

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]

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]

the Compact button from the customize toolbar palette just compacts the current folder.

Comment 33

[David :Bienvenu]

Attachment: 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)]

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]

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]

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]

I don't seem to be able to reproduce it anymore, but it was always somewhat intermittent.

Comment 38

[Bryan Clark (DevTools PM) [:clarkbw]]

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]

OK, I'll mark this fixed - if folks still see this with recent nightlies, we'll re-evaluate.

Comment 40

[David :Bienvenu]

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]

Attachment: 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)]

Comment on attachment 415186 [details] [diff] [review]
proposed fix

r/sr/a=Standard8

Comment 43

[David :Bienvenu]

changeset:   4469:8babd83ca9ec
tag:         tip
user:        David Bienvenu <[e-mail]>
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)]

(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)]

note, my two of my recent hangs are reported in  bug 524315

Comment 46

[Peep Chaintreuil]

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]

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]

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)]

Chris, the patch for this isn't in TB3b4 (circa september 15), so Eudora 8b8 wouldn't have it.

Comment 50

[Wayne Mery (:wsmwk)]

link up to http://gsfn.us/t/n2d1 report