shutdown hang, high cpu, no open imap connections

RESOLVED FIXED in Thunderbird 3

Status

MailNews Core
Networking: IMAP
P1
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: wsmwk, Assigned: Bienvenu)

Tracking

({fixed-seamonkey2.0.1, hang, qawanted})

Trunk
Thunderbird 3
x86
Windows Vista
fixed-seamonkey2.0.1, hang, qawanted
Bug Flags:
blocking-thunderbird3 +

Thunderbird Tracking Flags

(thunderbird3.0 .1-fixed)

Details

(Whiteboard: [no l10n impact][fixed RC2 build 1][gs], URL)

Attachments

(6 attachments)

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()
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
just noticed working set is < 1MB, so it's definitely pretty much shut down.
(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)
I just reproduced this with Bug 497059's tryserver TB 3.0b 090610 bienvenu shutdown

hopefully will have stacks later today
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
Flags: blocking-thunderbird3?
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Created attachment 387186 [details]
from T40 @home

20090704 nightly build.
nothing unusual about the shutdown, except I think indexing was in progress
(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?
(Assignee)

Comment 8

8 years ago
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.
FTR, just happened, XP, 0722 build (but haven't seen it much lately)

Updated

8 years ago
Flags: blocking-thunderbird3? → blocking-thunderbird3+

Updated

8 years ago
Whiteboard: [no l10n impact]
This feels like we should attack it in b4 if we can find the cause.
Target Milestone: --- → Thunderbird 3.0b4
(Assignee)

Comment 11

8 years ago
taking
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
(Assignee)

Updated

8 years ago
Whiteboard: [no l10n impact] → [no l10n impact][patch in bug 497059 might fix]
bleh, can't reproduce on demand now with 8/31 builds.  Will try at home tonight after hike with Gary
(Assignee)

Comment 13

8 years ago
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.
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.
(Assignee)

Comment 15

8 years ago
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.
20090909 hung tonight on vista
(Assignee)

Comment 17

8 years ago
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.
(Assignee)

Comment 18

8 years ago
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.
Attachment #399804 - Flags: superreview?(bugzilla)
Attachment #399804 - Flags: review?(bugzilla)
(Assignee)

Comment 19

8 years ago
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.
Attachment #399804 - Flags: superreview?(bugzilla)
Attachment #399804 - Flags: superreview+
Attachment #399804 - Flags: review?(bugzilla)
Attachment #399804 - Flags: review+
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.
(Assignee)

Updated

8 years ago
Attachment #399804 - Attachment description: don't tell the user about connection errors on shutdown → don't tell the user about connection errors on shutdown - checked in.
(Assignee)

Comment 21

8 years ago
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.
(Assignee)

Updated

8 years ago
Target Milestone: Thunderbird 3.0b4 → Thunderbird 3.0rc1
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
(Assignee)

Comment 23

8 years ago
yeah, better symbols would be very helpful.
AFAIK the patch in bug 497059 didn't fix it.
Whiteboard: [no l10n impact][patch in bug 497059 might fix] → [no l10n impact]

Comment 25

8 years ago
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.
(Assignee)

Updated

8 years ago
Priority: -- → P1
(Assignee)

Comment 26

8 years ago
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.
(Assignee)

Updated

8 years ago
Keywords: qawanted

Comment 27

8 years ago
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.
(Assignee)

Comment 28

8 years ago
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

8 years ago
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.
(Assignee)

Comment 30

8 years ago
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

8 years ago
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.
(Assignee)

Comment 32

8 years ago
the Compact button from the customize toolbar palette just compacts the current folder.
(Assignee)

Comment 33

8 years ago
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.
Attachment #402431 - Flags: superreview?(bugzilla)
Attachment #402431 - Flags: review?(bugzilla)
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.
Attachment #402431 - Flags: superreview?(bugzilla)
Attachment #402431 - Flags: superreview+
Attachment #402431 - Flags: review?(bugzilla)
Attachment #402431 - Flags: review+
(Assignee)

Updated

8 years ago
Attachment #402431 - Attachment description: fix some cases of hangs → fix some cases of hangs - checked in.
(Assignee)

Comment 35

8 years ago
patch checked in, with nits addressed. 

I doubt this will fix the problem clarkbw has been seeing - I'm working on reproducing that.
(Assignee)

Comment 36

8 years ago
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

8 years ago
I don't seem to be able to reproduce it anymore, but it was always somewhat intermittent.
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.
(Assignee)

Comment 39

8 years ago
OK, I'll mark this fixed - if folks still see this with recent nightlies, we'll re-evaluate.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 40

8 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 41

8 years ago
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.
Attachment #415186 - Flags: superreview?(bugzilla)
Attachment #415186 - Flags: review?(bugzilla)
Comment on attachment 415186 [details] [diff] [review]
proposed fix

r/sr/a=Standard8
Attachment #415186 - Flags: superreview?(bugzilla)
Attachment #415186 - Flags: superreview+
Attachment #415186 - Flags: review?(bugzilla)
Attachment #415186 - Flags: review+
Attachment #415186 - Flags: approval-thunderbird3.0.1+
Attachment #415186 - Flags: approval-thunderbird3+
(Assignee)

Comment 43

8 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.1a1
(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
status-thunderbird3.0: --- → .1-fixed
Whiteboard: [no l10n impact] → [no l10n impact][fixed RC2 build 1]
Target Milestone: Thunderbird 3.1a1 → Thunderbird 3
note, my two of my recent hangs are reported in  bug 524315

Comment 46

8 years ago
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
(Assignee)

Comment 47

8 years ago
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.

Updated

8 years ago
Keywords: fixed-seamonkey2.0.1

Comment 48

7 years ago
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.
Chris, the patch for this isn't in TB3b4 (circa september 15), so Eudora 8b8 wouldn't have it.
link up to http://gsfn.us/t/n2d1 report
Whiteboard: [no l10n impact][fixed RC2 build 1] → [no l10n impact][fixed RC2 build 1][gs]
You need to log in before you can comment on or make changes to this bug.