Had just updated from 3.0b2 to 3.0b3 and on exit it seemed like tb got itself into an endless loop. Sample attached Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3

Allan you are using POP or Imap ?

(In reply to comment #1) > Allan you are using POP or Imap ? IMAPS

That sample doesn't show anything IMAP-related that I can tell, but I'm not convinced those symbols match the actual stack since those stacks don't make complete sense (especially the stopwatch stuff).

I got this by compiling an opt build with symbols. It starts hanging not via the UI, but something in the background. i.e. after I finish sending a message, TB will refuse to start downloading new messages, and when I close TB, it hangs. This is the sample I got from the shutdown, with symbols. I will attach another stack in which I hooked gdb in to get a backtrace from all threads. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090806 Lightning/1.0pre Shredder/3.0b4pre

bienvenu, does this gdb stack from all threads help? (I got this the same time as when I got the activity manager stack above)

I'm not sure if the underlying issue reveals this to actually be a dupe of the other hang bugs lying around, but nominating confirming and blocking in case this is a legitimate hang of its own.

I've seen this behaviour too, also using IMAPs. I'll attach a process trace too, but it'll be from the public build.

(In reply to comment #8) > Created an attachment (id=393768) [details] > Activity Monitor process sample Seems to lack symbols too. See comment #4.

(In reply to comment #4) > It starts hanging not via > the UI, but something in the background. i.e. after I finish sending a message, > TB will refuse to start downloading new messages, and when I close TB, it > hangs. Yep, I think you are right about that. I just had it doing the exact same.

fixing fields so the radar is better :) Allan, Please report tests to help match the types of hangs we see: 1. cpu usage - is it high (pegged), zero, low, or other? 2. run netstat in a dos command window (or Mac equivalent) - how many connections are shown to your ldap server and (if imap) to your mail server? 3. if you are running lightning extension, does the shutdown hang happen without lightning?

In my case (on MacOS X 10.5.8) I get one core pegged at 100%, and I have no extensions loaded at all. I'll check for any outstanding TCP connections next time it happens.

also - there's no TB windows left on screen, but the Dock icon is still showing Thunderbird as an active app, but with the "this application is not responding" message.

high cpu hang comes in these flavors of open bugs: bug 420744 ldap connection open bug 494014 no open connections of any type bug 459265 lightning related zero cpu variation is bug 495551

I'm not running ldap, but running imaps. I'll look at netstat, etc. when it happens again -- I'm not 100% sure about the CPU usage.

oh, and the only compatible extension active is the Danish dictionary

I've just had this happen for the first time since upgrading to Snow Leopard (10.6). I can confirm that there are no TCP connections active at the time of the hang. I have 'lsof' output available if that's any use to anyone.

Ray, your reports do not indicate whether your testing is based on nightly or beta 3 (an important piece of context information). Although we might reasonably assume the later. If you haven't yet, please test the nightly ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ to see whether recently fixed bug 497059 or anything else has resolved this issue for you.

I've been testing 3.0b3, per the bug's subject line. I'll try the nightly build instead.

At the moment I feel we don't haven enough information to block on this even if we wanted to. There has been some shutdown improvements in bug 497059 since beta 3. I would therefore strongly recommend folks seeing this bug to try one of the nightly builds from ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ or the beta 4 preview when it is released. If more information comes available and the issue is still proven with the latest nightly builds, then please feel free to re-request blocking-thunderbird3.

Ok, this just happened again running the Shredder version (5th september build?). A portion of dtruss output will be attached. The predominant output is repeated calls to gettimeofday(), roughly twice per second. I had just started an IMAP "Compact", and I'm not sure that this had finished when I told Thunderbird to quit.

I've just attached gdb to the same running process: Continuing. ^C Program received signal SIGINT, Interrupt. 0x972df1b8 in spin_lock () (gdb) where #0 0x972df1b8 in spin_lock () #1 0x972df25b in pthread_mutex_lock () #2 0x0229c3e2 in PR_Lock () #3 0x02169e9f in nsThread::PutEvent () #4 0x002802bb in nsBaseAppShell::OnProcessNextEvent () #5 0x0024c8a3 in nsAppShell::OnProcessNextEvent () #6 0x0216a2bc in nsThread::ProcessNextEvent () #7 0x0212a233 in NS_ProcessNextEvent_P () #8 0x0216a99d in nsThread::Shutdown () #9 0x0216b288 in nsThreadManager::Shutdown () #10 0x0212ecf9 in NS_ShutdownXPCOM_P () #11 0x00004119 in ScopedXPCOMStartup::~ScopedXPCOMStartup () #12 0x00007568 in XRE_main () #13 0x00003893 in main () this stack trace looks a lot like the Windows debug traces given in bug 494014

Allan, Still need info re: comment 11/comment 14 Ray, If your symptoms match the summary of bug 494014 then you want to be there :)

(In reply to comment #24) > Allan, Still need info re: comment 11/comment 14 > > Ray, If your symptoms match the summary of bug 494014 then you want to be there > :) Allan is on vacation currently :-)

(In reply to comment #24) > Allan, Still need info re: comment 11/comment 14 If I had had more information I would have given it :) I've not had a hang since, and I answered that I was running plain vanilla install of 3.0b3, no extensions (except for disabled extensions and a Danish dictionary).

FWIW, I just had a hang on OS/X in Beta 4, with imgCacheEntry showing up in various places in the osx "report to apple" dialog. I'll try to remember netstat and cpu utilization next time. Though I don't think that cpu was high, I usually feel the heat quite rapidly.

(In reply to comment #24) > Ray, If your symptoms match the summary of bug 494014 then you want to be there I've added a note to 494014 - I think the hangs only happen if there's a "compact" operation in progress when I quit. What's needed to get the other reporters to confirm whether their symptoms match 494014, so we can merge the two? FWIW, the only previous reports for 494014 were on Windows systems.

these issues are not likely to be OS dependent. If your issue matches up we just dupe this bug to another. As for other reporters, that should refer to previous comments, including comment 11 and comment 14

Ive been getting the CPU spike on quit attempts for a long while, almost always when im trying to do a force update on the nightlies. I just presumed it was what i understood was the IMAP Mac OS quit thing, but as this is still unco... :| What kinda info are we looking for? A sample log?

(In reply to comment #30) > Ive been getting the CPU spike on quit attempts for a long while, almost always > when im trying to do a force update on the nightlies. I just presumed it was > what i understood was the IMAP Mac OS quit thing, but as this is still unco... > :| > > What kinda info are we looking for? A sample log? A way to reproduce in all cases , not just once in a while. If you can come up with that would be great. If you can't and feel like sampling the application until it happens again that would also be useful.

Aha, just happened again, on b4 (In reply to comment #11) > Allan, Please report tests to help match the types of hangs we see: > 1. cpu usage - is it high (pegged), zero, low, or other? cpu is pegged. > 2. run netstat in a dos command window (or Mac equivalent) - how many > connections are shown to your > ldap server and (if imap) to your mail server? The machine had been in standby for a while after I tried closing tb, so dunno. > 3. if you are running lightning extension, does the shutdown hang happen > without lightning? Extensions installed: Danish dictionary, Nostalgy, Zindus. I do not know if it would make a difference with or without these -- on 3.0b3 it happened with only the Danish dict installed. I've attached a new sample.

Allan, I would suggest running http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ because 3.0b4 is now 1.5 months old, and at least 4 hang bugs have been fixed: bug 495551, bug 420744, bug 494014, bug 518128 I've not had a hang for a weeks or two, so my problem might be gone (though I wouldn't swear to it), and yours might be gone too.

Running a nightly would also get you a sample with reliable symbols as we now include symbols on nightly builds.

Well over hte past few days, I haven't gotten it to happen. I am going to see if I can induce it by doing some IMAP traffic at the time of the forced update.

fwiw, I'd be cautious about declaring any infrequent hang gone - I hung a couple days ago on a recent trunk build ... and I hadn't seen a hang in about two weeks.

bug 494014 checked in another patch. so please install ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ and report back results. If reporter is still solid with no hangs we'll close this bug.

I've been running 3.0rc1 for a while now. Hanging for the first time now. Could it be related to losing the network connection/sleeping? I cannot be 100% sure, but it might only happen after putting my laptop to sleep at some point. Will install rc2 now, but I suppose it just missed the above check in?

It could be related to losing the network connection/sleeping. The fix in rc2 won't help you, however - that was for a very specific instance of this problem that would cause the hang on shutdown every time you ran.

Well I got a hang today, trying to drop an update. I'll attach the sample log. I hope it helps

Was getting frequent hangs all through betas (assumed that was the kind of bug that would be taken seriously and squashed -- after reading this bug thread, surprised and frustrated that it wasn't). Now on "3.0" same issue: as above, TB seemingly hangs attempting to get IMAP mail (waiting cursor when .INBOX is selected), then the UI closes but the app doesn't, pegging one CPU at ~ 100%. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 I have IMAP logs if that's useful. No extensions.

Allan, yes RC1 did not have the checkin David in comment #42 > Was getting frequent hangs all through betas (assumed that was the kind of bug > that would be taken seriously and squashed -- after reading this bug thread, > surprised and frustrated that it wasn't). a) since you followed the hang bugs you also know that several were fixed b) the target of your frustration *this bug* is quite misplaced. reporter's issue had (and still has) no clear steps to reproduce, and indeed for a long time not much information about the circumstances regarding the hang. > Now on "3.0" same issue: as above, TB seemingly hangs attempting to get IMAP > mail (waiting cursor when .INBOX is selected), then the UI closes but the app > doesn't, pegging one CPU at ~ 100%. different issue. please file a bug if there isn't already (but I think I did see one...please do a thorough search). Please state the following when creating your bug: cpu: high, low or zero netstat: ldap, imap or any other thunderbird related connections open steps reproduced with thunderbird started in safe mode preferably

(In reply to comment #43) > different issue. please file a bug if there isn't already (but I think I did > see one...please do a thorough search). Please state the following when > creating your bug: > cpu: high, low or zero > netstat: ldap, imap or any other thunderbird related connections open > steps reproduced with thunderbird started in safe mode preferably Ok, I was trying to be helpful (thanks for not shooting me down), found a number of crash bugs, but this one was the only existing bug with the exact same symptoms I've been experiencing: * Hanging via background process (not through a UI event) * TB will refuse to start downloading new messages * When I close TB it hangs (no GUI but "This application is not responding") * Hung one cpu at 100% But if you think it's different, i'll spend another fifteen minutes fighting bugzilla to find another bug that also sounds similar, no problem.

there is no way to definitively tie your situation to this for reasons I previously stated, and because neither yours nor Allan's has results from netstat. Who knows, they may ultimately and up being the same problem. But working >1 person's issue in the same bug with seemingly similar symptoms often is an exercise in frustration, with multiple conversations and symptoms weaving around. So it is best to file a new bug -- unless you and Allan suddenly come up with similar steps and netstat results. observation: in Mac world it seems common to refer to situation where the application stops working as a crash. However, this in fact conflates to distinct situations: hang - application is running but there is no response crash - application is not running here, a hang is not a crash.

(In reply to comment #45) > there is no way to definitively tie your situation to this for reasons I > previously stated, and because neither yours nor Allan's has results from > netstat. Hung again. Again after sleep. Ran netstat, and there are no open imap connections.

possible dups based on Allan's info: Bug 531428 - TB don´t shutdown, high cpu Bug 524315 - shutdown hang, high cpu, no open imap connections, no ldap connections

DavidB anything of interest in the provided stacks ?

The imap threads are trying to read data but nothing is coming - this is after putting the machine to sleep? Necko might be noticing the OS going offline and disabling itself in the middle of imap trying to read data. For some reason, Necko can get into a state where timeouts don't work...

Im starting to see a pattern, it has to do with waking from sleep. When trying to check new mail from the inbox (gmail imap), it was just repeatedly busy. It had the mouse pointer with the working busy ball. I was able to open other mailboxes and look at them, and that activity was listed in the activity viewer. But whatever it was trying to do with the inbox was stuck in some way. Trying to quit the app caused a CPU spike.

I should mention that I cleared the activity viewer and nothing was listed when i tried to quit. Is there a connection debug mode or something?

I'm getting more and more confident that this has something to do with sleep. My best reproducible scenario is: 1. open tb 2. close laptop 3. open laptop 4. click 'Get Mail' 5. if step 4 does not hang, go to step 2 :)

Allan: I am inclined to agree with you, and I think it might be gecko related, as im starting to have a similar issue with the 3.5 and 3.6 series of FF. I can, if someone thinks it will be of value, try a sample before a quit is attempted, and then sample while it hanging.

Well I'm still having this, and I think its tied to sleep somehow. I am now going to try and go into offline mode before I quit the app to see if that has any effect.

Well a bit of unscientific testing, the past 4 days I have switched to offline prior to attempting to quit TB, and none of the times its been offline it hangs. All the times quitting were between sessions of which the system was asleep for several hours

My feeling is that this is mac only, as I havent seen this behavior on my win 7 netbook which also does nothing but sleep/suspend/hibernate when i use it.

The problem is still in TB 3.0.4. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

This is very strange - 2389 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2389 nsStopwatch::QueryInterface(nsID const&, void**) 2389 nsStopwatch::QueryInterface(nsID const&, void**) 2389 nsStopwatch::QueryInterface(nsID const&, void**) 2389 nsStopwatch::QueryInterface(nsID const&, void**) 2389 nsStopwatch::QueryInterface(nsID const&, void**) 2389 non-virtual thunk to nsPrintSession::Release() 2389 nsLinebreakConverter::ConvertUnicharLineBreaks(unsigned short const*, nsLinebreakConverter::ELinebreakType, nsLinebreakConverter::ELinebreakType, int, int*) 2389 NS_NewPipe(nsIInputStream**, nsIOutputStream**, unsigned int, unsigned int, int, int, nsIMemory*) 2389 NS_NewPipe(nsIInputStream**, nsIOutputStream**, unsigned int, unsigned int, int, int, nsIMemory*)

I had nearly the same issue - a hanging process and high cpu, using imap with enigmail and a dictionary installed. The problem seems to be solved now since I have updated the dictionary 'Deutsch (de-DE)' Hunspell-supported. @Allan: try it with a disabled/uninstalled dictionary.

(In reply to comment #59) > Created an attachment (id=438695) [details] > Thunberbird process sample from Avtivity Monitor Essentially the same sample trace, but with multiple threads all waiting on semaphore_wait_signal_trap. Can post full trace if requested. At least three threads are running, but I only have two mail accounts configured (not counting the local account, which is not in use). Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100430 Thunderbird/3.1b2. Mac Os X 10.6.3. I've been having this problem (hang at exit, 100% CPU) since at least 3.0, possibly earlier.

i did a search because i was having this same problem and was presented with this bug. perhaps what i'm experiencing is a duplicate. i opened "Activity Monitor" and took a "sample", and here's what it reports. hope it helps. Sampling process 16886 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling thunderbird-bin (pid 16886) every 1 millisecond Call graph: 2460 Thread_5271145 DispatchQueue_1: com.apple.main-thread (serial) 2460 start 2460 start 2460 start 2460 XRE_main 2460 start 2460 NS_GetTraceRefcnt_P 2460 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2460 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2456 NS_ProcessNextEvent_P(nsIThread*, int) 2422 NS_SetGlobalThreadObserver(nsIThreadObserver*) 1955 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 1298 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 567 NS_SetGlobalThreadObserver(nsIThreadObserver*) 264 nsEventQueue::PutEvent(nsIRunnable*) 137 PR_ExitMonitor 128 PR_Unlock 109 PR_DestroyCondVar 31 PR_DestroyCondVar 30 __spin_lock 22 pthread_mutex_unlock 19 pthread_mutex_unlock 2 spin_lock 1 spin_unlock 20 pthread_cond_broadcast 19 pthread_cond_broadcast 1 spin_unlock 5 dyld_stub__spin_unlock 1 PR_AtomicDecrement 10 PR_Now 7 PR_Unlock 2 dyld_stub_pthread_mutex_unlock 5 PR_ExitMonitor 3 pthread_equal 1 pthread_self 57 PR_EnterMonitor 45 PR_Lock 23 pthread_mutex_lock 21 pthread_mutex_lock 2 spin_unlock 15 __spin_lock 4 PR_Lock 2 pthread_self 1 dyld_stub__spin_lock 7 PR_EnterMonitor 2 dyld_stub_pthread_mutex_lock 2 dyld_stub_pthread_self 1 pthread_self 45 PR_NotifyAll 26 PR_AssertCurrentThreadOwnsLock 25 PR_AssertCurrentThreadOwnsLock 1 PR_AtomicIncrement 17 PR_Now 2 PR_NotifyAll 18 nsEventQueue::PutEvent(nsIRunnable*) 3 dyld_stub_pthread_self 3 nsRunnable::AddRef() 1 dyld_stub_pthread_equal 98 PR_Lock 41 __spin_lock 40 pthread_mutex_lock 38 pthread_mutex_lock 1 spin_lock 1 spin_unlock 10 PR_Lock 4 dyld_stub__spin_lock 2 dyld_stub__spin_unlock 1 pthread_self 73 PR_Unlock 25 pthread_mutex_unlock 21 pthread_mutex_unlock 4 spin_lock 23 __spin_lock 17 PR_Unlock 4 dyld_stub__spin_unlock 4 pthread_equal 33 NS_SetGlobalThreadObserver(nsIThreadObserver*) 33 nsCOMPtr_base::~nsCOMPtr_base() 12 PR_Now 12 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 11 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 1 PR_AtomicDecrement 4 dyld_stub_PR_AtomicDecrement 4 nsCOMPtr_base::~nsCOMPtr_base() 1 PR_AtomicDecrement 30 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 18 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 12 PR_Now 14 PR_Now 7 dyld_stub_pthread_self 4 NS_SetGlobalThreadObserver(nsIThreadObserver*) 4 PR_AtomicIncrement 3 dyld_stub_pthread_equal 1 PR_NotifyAll 1 dyld_stub_PR_EnterMonitor 1 dyld_stub_pthread_mutex_unlock 1 nsRunnable::AddRef() 295 NS_HasPendingEvents_P(nsIThread*) 271 NS_SetGlobalThreadObserver(nsIThreadObserver*) 227 nsEventQueue::GetEvent(int, nsIRunnable**) 103 PR_ExitMonitor 83 PR_Unlock 43 pthread_mutex_unlock 39 pthread_mutex_unlock 3 spin_unlock 1 spin_lock 26 __spin_lock 9 PR_Unlock 3 pthread_equal 1 dyld_stub__spin_lock 1 pthread_self 12 PR_ExitMonitor 3 pthread_equal 2 dyld_stub_pthread_equal 2 dyld_stub_pthread_self 1 pthread_self 98 PR_EnterMonitor 81 PR_Lock 44 pthread_mutex_lock 40 pthread_mutex_lock 3 spin_lock 1 spin_unlock 29 __spin_lock 7 PR_Lock 1 dyld_stub__spin_unlock 8 PR_EnterMonitor 4 dyld_stub_pthread_mutex_lock 3 pthread_equal 2 dyld_stub_pthread_self 17 nsEventQueue::GetEvent(int, nsIRunnable**) 5 dyld_stub_pthread_self 4 dyld_stub_pthread_equal 24 NS_SetGlobalThreadObserver(nsIThreadObserver*) 16 PR_GetCurrentThread 13 PR_GetCurrentThread 3 pthread_getspecific 2 dyld_stub_PR_EnterMonitor 2 dyld_stub_pthread_getspecific 21 NS_HasPendingEvents_P(nsIThread*) 3 dyld_stub_PR_GetCurrentThread 198 PR_Now 183 gettimeofday 165 __gettimeofday 97 __nanotime 68 __gettimeofday 16 gettimeofday 2 __commpage_gettimeofday 14 PR_Now 1 dyld_stub___commpage_gettimeofday 126 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 35 __addHandler2 27 __addHandler2 8 pthread_getspecific 35 __removeHandler2 34 __removeHandler2 1 pthread_getspecific 30 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 14 objc_exception_try_exit 8 objc_exception_try_enter 4 dyld_stub_pthread_getspecific 29 PR_MillisecondsToInterval 17 PR_Now 6 PR_MillisecondsToInterval 6 PR_TicksPerSecond 28 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 27 _setjmp 6 PR_IntervalNow 6 dyld_stub_objc_exception_try_exit 4 dyld_stub_PR_Unlock 2 dyld_stub_PR_AtomicIncrement 2 dyld_stub_PR_Lock 2 dyld_stub__setjmp 2 objc_exception_try_enter 1 PR_AtomicIncrement 1 dyld_stub_gettimeofday 1 dyld_stub_objc_exception_try_enter 1 objc_exception_try_exit 187 -[NSAutoreleasePool release] 133 NSPopAutoreleasePool 56 _CFAutoreleasePoolPop 21 _CFAutoreleasePoolPop 21 pthread_setspecific 6 pthread_getspecific 4 pthread_equal 2 _objc_getFreedObjectClass 2 objc_collectingEnabled 14 NSPopAutoreleasePool 13 __addHandler2 12 __addHandler2 1 pthread_getspecific 11 _CFExecutableLinkedOnOrAfter 10 dyld_stub_pthread_getspecific 9 __removeHandler2 7 objc_collectingEnabled 6 objc_exception_try_exit 3 objc_exception_try_enter 2 dyld_stub_objc_collectingEnabled 1 dyld_stub__objc_getFreedObjectClass 1 dyld_stub_pthread_setspecific 14 _setjmp 14 objc_removeAssociatedObjects 10 objc_removeAssociatedObjects 4 _class_instancesHaveAssociatedObjects 8 -[NSAutoreleasePool release] 8 OSAtomicCompareAndSwapPtrBarrier 4 dyld_stub_objc_collectingEnabled 3 dyld_stub__CFAutoreleasePoolPop 1 dyld_stub__CFExecutableLinkedOnOrAfter 1 dyld_stub_objc_exception_try_enter 1 dyld_stub_objc_exception_try_exit 103 CFArrayRemoveValueAtIndex 91 _CFArrayReplaceValues 59 _CFArrayReplaceValues 24 __CFArrayReleaseValues 8 __bzero 7 CFArrayRemoveValueAtIndex 3 memset 2 dyld_stub_memset 72 CFArrayAppendValue 62 _CFArrayReplaceValues 55 _CFArrayReplaceValues 5 __memcpy 2 objc_memmove_collectable 8 CFArrayAppendValue 2 dyld_stub_objc_memmove_collectable 50 -[NSAutoreleasePool init] 37 _CFAutoreleasePoolPush 15 _CFAutoreleasePoolPush 13 pthread_setspecific 5 objc_collectingEnabled 2 pthread_getspecific 2 pthread_self 4 -[NSAutoreleasePool init] 4 NSPushAutoreleasePool 2 NSPushAutoreleasePool 2 objc_collectingEnabled 2 dyld_stub_objc_collectingEnabled 2 dyld_stub_pthread_getspecific 1 dyld_stub_pthread_self 47 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 43 +[NSObject(NSObject) alloc] 16 +[NSAutoreleasePool allocWithZone:] 8 +[NSAutoreleasePool allocWithZone:] 8 OSAtomicCompareAndSwapPtrBarrier 14 OSAtomicCompareAndSwapPtrBarrier 14 __compare_and_swap32 7 +[NSObject(NSObject) alloc] 3 dyld_stub_OSAtomicCompareAndSwapPtrBarrier 2 objc_msgSend 1 __compare_and_swap32 40 __removeHandler2 38 __removeHandler2 2 pthread_getspecific 26 __addHandler2 25 __addHandler2 1 pthread_getspecific 21 objc_msgSend 15 OSAtomicCompareAndSwapPtrBarrier 15 __compare_and_swap32 12 CFArrayGetCount 9 objc_exception_try_exit 6 CFArrayGetValueAtIndex 5 objc_exception_try_enter 4 PR_Now 4 dyld_stub_pthread_getspecific 3 dyld_stub_NS_HasPendingEvents_P(nsIThread*) 3 dyld_stub_PR_IntervalNow 2 dyld_stub__CFAutoreleasePoolPush 2 dyld_stub_objc_removeAssociatedObjects 1 __compare_and_swap32 1 dyld_stub_PR_MillisecondsToInterval 1 dyld_stub_objc_msgSend 132 nsEventQueue::GetEvent(int, nsIRunnable**) 60 PR_ExitMonitor 49 PR_Unlock 19 __spin_lock 19 pthread_mutex_unlock 6 PR_Unlock 2 dyld_stub__spin_lock 2 pthread_equal 1 pthread_self 5 PR_ExitMonitor 2 dyld_stub_pthread_mutex_unlock 2 dyld_stub_pthread_self 1 pthread_equal 1 pthread_self 59 PR_EnterMonitor 52 PR_Lock 29 pthread_mutex_lock 24 pthread_mutex_lock 4 spin_lock 1 spin_unlock 13 __spin_lock 5 PR_Lock 3 pthread_self 2 dyld_stub__spin_lock 3 dyld_stub_pthread_mutex_lock 2 PR_EnterMonitor 1 dyld_stub_pthread_self 1 pthread_equal 5 nsEventQueue::GetEvent(int, nsIRunnable**) 4 dyld_stub_pthread_equal 4 dyld_stub_pthread_self 115 XRE_GetFileFromPath 53 XRE_GetFileFromPath 26 PR_GetCurrentThread 22 PR_GetCurrentThread 4 pthread_getspecific 15 nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) 7 dyld_stub_pthread_getspecific 7 nsTArray_base::EnsureCapacity(unsigned int, unsigned int) 7 nsTArray_base::ShrinkCapacity(unsigned int) 57 nsCOMPtr_base::~nsCOMPtr_base() 31 PR_Now 9 nsCOMPtr_base::~nsCOMPtr_base() 9 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 8 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 1 PR_AtomicDecrement 4 nsRunnable::Release() 3 dyld_stub_PR_AtomicDecrement 1 PR_AtomicDecrement 54 NS_SetGlobalThreadObserver(nsIThreadObserver*) 42 _setjmp 29 objc_msgSend 6 nsCOMPtr_base::begin_assignment() 5 dyld_stub_objc_msgSend 4 PR_GetCurrentThread 3 PR_GetCurrentThread 1 pthread_getspecific 4 nsRunnable::Run() 3 dyld_stub_PR_GetCurrentThread 3 objc_exception_try_exit 2 dyld_stub_CFArrayRemoveValueAtIndex 2 dyld_stub_PR_EnterMonitor 2 dyld_stub_PR_ExitMonitor 2 dyld_stub__setjmp 1 PR_AtomicIncrement 1 dyld_stub_CFArrayGetValueAtIndex 1 dyld_stub_objc_exception_try_enter 1 dyld_stub_pthread_getspecific 1 objc_exception_try_enter 16 PR_Now 11 NS_ProcessNextEvent_P(nsIThread*, int) 4 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 2 XRE_GetFileFromPath 1 dyld_stub_PR_AtomicIncrement 4 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2460 Thread_5271151 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2460 start_wqthread 2460 _pthread_wqthread 2460 _dispatch_worker_thread2 2460 _dispatch_queue_invoke 2460 _dispatch_mgr_invoke 2460 kevent 2460 Thread_5271152 2460 thread_start 2460 _pthread_start 2460 XRE_GetFileFromPath 2460 mach_msg 2460 mach_msg_trap 2460 Thread_5271155 2460 thread_start 2460 _pthread_start 2460 PR_Select 2460 js_ValueToCharBuffer 2460 PR_WaitCondVar 2460 pthread_cond_wait 2460 _pthread_cond_wait 2460 semaphore_wait_signal_trap 2460 Thread_5271156 2460 thread_start 2460 _pthread_start 2460 PR_Select 2460 XRE_GetFileFromPath 2460 PR_WaitCondVar 2460 PR_AssertCurrentThreadOwnsLock 2460 pthread_cond_timedwait 2460 _pthread_cond_wait 2460 semaphore_timedwait_signal_trap 2460 Thread_5287153 2460 thread_start 2460 _pthread_start 2460 PR_Select 2460 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2460 NS_ProcessNextEvent_P(nsIThread*, int) 2460 NS_SetGlobalThreadObserver(nsIThreadObserver*) 2460 nsStopwatch::Resume() 2460 nsStopwatch::Resume() 2460 nsStopwatch::Resume() 2460 nsStopwatch::Resume() 2460 nsStopwatch::Resume() 2460 JNIEnv_::CallStaticObjectMethod(_jclass*, _jmethodID*, ...) 2460 NS_CopyUnicodeToNative(nsAString_internal const&, nsACString_internal&) 2460 NS_NewPipe(nsIInputStream**, nsIOutputStream**, unsigned int, unsigned int, int, int, nsIMemory*) 2460 PR_Wait 2460 PR_WaitCondVar 2460 pthread_cond_wait 2460 _pthread_cond_wait 2460 semaphore_wait_signal_trap Total number in stack (recursive counted multiple, when >=5): 10 PR_Now 10 dyld_stub_pthread_self 10 pthread_getspecific 10 pthread_self 9 pthread_equal 8 NS_SetGlobalThreadObserver(nsIThreadObserver*) 8 __spin_lock 7 dyld_stub_pthread_getspecific 7 spin_unlock 7 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 6 spin_lock 5 PR_AtomicDecrement 5 dyld_stub__spin_lock 5 dyld_stub_pthread_equal 5 nsStopwatch::Resume() 5 objc_exception_try_enter 5 objc_exception_try_exit Sort by top of stack, same collapsed (when >= 5): semaphore_wait_signal_trap 4920 kevent 2460 mach_msg_trap 2460 semaphore_timedwait_signal_trap 2460 __spin_lock 196 PR_Now 147 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) 146 pthread_mutex_lock 123 NS_SetGlobalThreadObserver(nsIThreadObserver*) 119 _CFArrayReplaceValues 114 pthread_mutex_unlock 98 __nanotime 97 _setjmp 83 __removeHandler2 81 __gettimeofday 68 __addHandler2 64 XRE_GetFileFromPath 55 objc_msgSend 52 PR_Unlock 39 PR_GetCurrentThread 38 pthread_setspecific 34 objc_exception_try_exit 33 PR_DestroyCondVar 31 __compare_and_swap32 31 dyld_stub_pthread_getspecific 30 dyld_stub_pthread_self 29 pthread_getspecific 29 PR_Lock 26 PR_AssertCurrentThreadOwnsLock 25 __CFArrayReleaseValues 24 pthread_equal 24 PR_ExitMonitor 22 nsEventQueue::GetEvent(int, nsIRunnable**) 22 NS_HasPendingEvents_P(nsIThread*) 21 _CFAutoreleasePoolPop 21 objc_exception_try_enter 19 pthread_cond_broadcast 19 nsEventQueue::PutEvent(nsIRunnable*) 18 PR_EnterMonitor 17 OSAtomicCompareAndSwapPtrBarrier 16 gettimeofday 16 objc_collectingEnabled 16 _CFAutoreleasePoolPush 15 nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) 15 spin_lock 15 NSPopAutoreleasePool 14 dyld_stub_pthread_equal 14 pthread_self 14 nsCOMPtr_base::~nsCOMPtr_base() 13 CFArrayGetCount 12 dyld_stub__spin_unlock 12 NS_ProcessNextEvent_P(nsIThread*, int) 11 _CFExecutableLinkedOnOrAfter 11 dyld_stub__spin_lock 10 objc_removeAssociatedObjects 10 spin_unlock 10 dyld_stub_pthread_mutex_lock 9 +[NSAutoreleasePool allocWithZone:] 8 -[NSAutoreleasePool release] 8 CFArrayAppendValue 8 __bzero 8 dyld_stub_objc_collectingEnabled 8 +[NSObject(NSObject) alloc] 7 CFArrayRemoveValueAtIndex 7 PR_AtomicIncrement 7 dyld_stub_PR_AtomicDecrement 7 dyld_stub_objc_exception_try_exit 7 nsTArray_base::EnsureCapacity(unsigned int, unsigned int) 7 nsTArray_base::ShrinkCapacity(unsigned int) 7 CFArrayGetValueAtIndex 6 PR_IntervalNow 6 PR_MillisecondsToInterval 6 PR_TicksPerSecond 6 dyld_stub_PR_GetCurrentThread 6 dyld_stub_objc_msgSend 6 nsCOMPtr_base::begin_assignment() 6 PR_AtomicDecrement 5 __memcpy 5 dyld_stub_PR_EnterMonitor 5 dyld_stub_pthread_mutex_unlock 5 Sample analysis of process 16886 written to file /dev/stdout

Please don't use the comment fields for long logs, long traces, long anythings; include such info as an "attachment" (with explanatory comments, if the normal one-line entry isn't enough). > [...] and here's what it reports. hope it helps. [...] It might help, it might not -- but it sure takes a long time to scroll past it....

sorry to ruin your scroll finger/thumb. try the "[-]" next to it and it won't take so long. i would edit it and attach as you suggested, but apparently that's not something bugzilla allows. will remember your advice next time.

So i've been trying to look closer at the outward signs of this. I see in the main tab the little 'working' spinny thingy, but the activity viewer shows no activity. If there a way to turn off the network up/down detection feature (aka assume its on) and see if this has an effect?

So, whatever weird state TB gets in when the system wakes from sleep, I have noticed another weird behavior. I set TB to offlien use to try and get it to drop whatever connection it thinks is open, to quit gracefully. I get a status message at the bottom 'downloading mail for offline use, but no actual network activity. after several minutes I try and quit the app and *bam* runaway.

Possible insight. I was using my laptop for over an hour but did not bring TB to the front, but it was still running, so for nearly an hour no mail was downloaded. Not until I brought it forward did it seem to work really hard to (more than 10 secs) to get 6 pieces of mail. Sadly however, even after this successful connection and download, it still goes runaway when attempting to quit

I think what would be useful at this stage is to confirm that this bug is still in the latest 3.1.x builds, and that the failure is the same. So if you're still seeing it in 3.1.6 (or .7 when it comes out later this week), then we'll need a stack trace sample obtained via the Activity Monitor. However the stack trace *must* be from a nightly build. Using a released build the symbols won't be valid as we don't ship symbols for those builds. You can get nightly builds from here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ I'm going to mark some attachments obsolete - these will be the ones that I believe have invalid stack symbols due to previously using released builds rather than nightly builds.

(In reply to comment #71) > So if you're still seeing it in 3.1.6 (or .7 when it comes out later this > week), then we'll need a stack trace sample obtained via the Activity Monitor. > > However the stack trace *must* be from a nightly build. Using a released build > the symbols won't be valid as we don't ship symbols for those builds. You can > get nightly builds from here: > > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ Oh and if you do attach a sample from the activity monitor, please also include the full Thunderbird version details obtained from Help -> About.

yep, it still exists. Happens all the time to me. Bonus is that it crashes OS X if I try to force quit it from the launcher. Usually resort to 'kill -9' to be safe. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

Still happens to me too on 3.1.7. Maybe this is helpful: I found that when I moved off my old IMAP (Courier) on to Gmail IMAP, the problem happened much more infrequently -- in fact it may only happen when I accidentally open up my old account. Difficult to know because there's some latency between checking the account and an actual crash.

(In reply to comment #74) > Still happens to me too on 3.1.7. > > Maybe this is helpful: I found that when I moved off my old IMAP (Courier) on > to Gmail IMAP, the problem happened much more infrequently -- in fact it may > only happen when I accidentally open up my old account. Difficult to know > because there's some latency between checking the account and an actual crash. Hi David. Your case sounds interesting. Please file a new bug with an imap:5 protocol log - https://wiki.mozilla.org/MailNews:Logging - and corresponding stack trace (or crash report) for the developer.

I can pretty easily reproduce this - have to let TB run for a while, most likely including putting machine to sleep at least once. The attachment is the Apple crash report sample (about 3/4 file) and a sample from during the hang but before the force quit (last 1/4 file)

(In reply to comment #76) > Created attachment 495704 [details] whoops forgot: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14pre) Gecko/20101206 Lanikai/3.1.8pre ID:20101206030725

Still having it also. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14pre) Gecko/20101206 Lightning/1.0b2 Lanikai/3.1.8pre

Attached a zip with imap:5 protocol log that was requested. I anonymized the log by removing message contents (awk script included - just for reference - and maybe useful for others too), and by replacing user/server/folder names. Imap log is from start of TB till forced quit; there was at least one normal sleep cycle (after which TB worked properly), but after last wakeup from sleep I got spinning disc on the inbox. At the same time, the log kept growing, so TB was not in a deadlock yet. I attached gdb, and sampled some backtraces. Then I quit TB normally, which resulted in TB hanging. I again sampled some backtraces. Finally I Force Quit TB. The gdb output is also included, with annotations on when I quit TB and when I used Force Quit. Hope this helps, as this is quite an annoying bug.

To be complete: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

Unfortunately, nothing looks wrong in Paul's logs. There are no threads blocked in imap (no imap threads at all, from what I can tell).

I've been living with this bug through several Thunderbird upgrades, hoping it would go away - finally I decided to see if it was being addressed and ran across this bug report. Yes, I still see it. I'm running Mac OS X 10.6.5 on a MacBook Pro (2.8 GHz Intel Core 2 Duo) Thunderbird version: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 I'm not running any additional plugins with TB, no Lightning etc. I connect to two mailboxes via IMAP. One of these never has problems; the other (my work mailbox although both get roughly equal amounts of traffic) regularly hangs after the laptop wakes up from a sleep. There's no sign of an open IMAP network connection, and TB isn't using much CPU until I try to quit (using Command-Q or the Dock) at which point CPU usage by thunderbird goes to 100% and I have to force-quit or kill -9 for it to go away. The bug doesn't happen with every wake-from-sleep, but perhaps 30% of the time. It's also rather annoying because I often don't notice I'm not getting my work mail until 30 minutes or more into the day, when I see the little circle icon or somebody mentions an email I haven't seen yet. It's been the same bug at least since the first 3.0 version of Thunderbird, when I updated last year. Account settings for the account that sees the hang (my work account): Port: 993 Connection security: SSL/TLS Authentication method: Normal password Check for new messages at startup Check for new messages every 10 minutes When I delete a message - move it to Trash Clean up ("Expunge") Inbox on Exit Settings for the account that never sees the hang: Port: 143 Connection security: None Authentication method: Password, transmitted insecurely Check for messages every 10 minutes When I delete a message - move it to Trash Something related to the SSL/TLS security settings?

Thanks Please see the following, and ensure that your symptoms matches the bug [1] you are commenting in https://wiki.mozilla.org/Thunderbird:Testing:Shutdown_Hang If so noted in the wiki, please also attach a protocol log file do the bug. [1] shutdown bugs you can check to see if they match your situation: https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&keywords=hang&keywords_type=allwords&short_desc=shut%20down%20&field0-0-0=short_desc&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&classification=Client%20Software&classification=Components&chfieldto=Now&query_format=advanced&chfieldfrom=2009-01-01&short_desc_type=allwordssubstr&type0-0-0=anywordssubstr&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc

Wayne, I went to that page first; my symptoms seem to match what's described on this page, and there is no other open bug in your list that is indicated as applying to the Mac version of Thunderbird. I don't have a hang stack trace yet, but I found this page this morning: https://wiki.mozilla.org/Thunderbird:Testing:Get_A_Debug_Thunderbird_Hang_Stack and will send that when I can get it to work.

I'm not sure this is a backtrace of the actual symptom case. I tried getting TB to freeze all day by putting the laptop to sleep and waking again, even switched from wired to wireless connection (but still within the office). Then went home, laptop was asleep for about 2 hours 40 minutes, and reconnected on the home network, and it finally froze connecting to my work mailbox. I had started the process with thunderbird-bin as described here: https://wiki.mozilla.org/Thunderbird:Testing:Get_A_Debug_Thunderbird_Hang_Stack then at the time of the hang I attached with gdb as described there. Thunderbird was hung so I typed 'cont' to continue; gdb's prompt did not return so I hit 'ctrl-c', then did the "thread apply all bt" and got the attached stack trace. I think hit 'cont', and then Thunderbird->Quit, and it actually quit without going into the 100%-CPU mode. And of course no backtrace possible at that point. So this may be a different issue than the real bug of concern. Anyway, I'll try again, but posting this for reference.

I don't see any imap threads (or ldap threads - do you use ldap auto complete?) in those backtraces.

I'd like to add in here a possible perception of behavior on this bug. I have noticed that after waking from sleep, it takes a *very* long time for it to automatically get new mail again. Much much longer than if one starts form TB not being run already. So I have the perception that if you try to quit before it manages to check email, it seems to quit and not hang. I'd like to see if anyone can confirm this. my singular sample size isn't enough.

David - I don't believe I do anything with ldap, though I may have once configured that and forgotten about it. How can I tell? Lint - I'm not sure what you're asking, but normally after wake from sleep I see new mail within a few minutes. If I hit the "Get Mail" button the mail comes through immediately. Except when I encounter this hang bug - as I said, new mail doesn't appear even if I wait as long as 30 minutes, the little "busy" circle is twirling or whatever it does, and when I actually quit Thunderbird it doesn't quit, but CPU use hits 100%, and I have to Force-Quit or kill -9. Now, I apologize that I haven't yet been able to get a proper stack trace that I'm confident is showing the problem. I've been running thunderbird-bin almost 3 days straight now with dozens of sleep-wake cycles, switching between wired and several different wireless networks at work, at home, on the train (Verizon 3g) and haven't had a single additional hang/crash. This seems much longer than usual between problems, but I'm going to keep at it for another few days just to see if it ever triggers. Could it be from something different between starting thunderbird-bin on the command line and starting the app from the Dock??? Any suggestions?

(In reply to comment #88) > David - I don't believe I do anything with ldap, though I may have once > configured that and forgotten about it. How can I tell? > It would be one of your address books, if you'd configured an ldap server, and the address book line would look more like a globe than an address book, at least in my theme. Seems unlikely. Flaky network connections might make this problem easier to recreate. Perhaps your network connections have been more reliable than usual.

I do not use LDAP, and I'm always on the same network

After over 3 days running, finally coming in to the office this morning TB went into a hanging state again (and this time hung on both mailboxes, not just the work one). After 20 minutes of no mail downloaded I did the gdb attach, and this time *didn't* continue/ctrl-C, and got the attached stacktrace. It's almost identical to the previous one I posted (except with different process id and thread numbers) - differences seem to be an additional Thread 11 and oddly different #5- later for Thread 16 (15 in the original). After doing a cont/ctrl-C I did another backtrace which was identical to this one except that Thread 18 became Thread 19. I then did 'Quit' via the dock and it actually quit without going to 100% CPU. So again I'm not sure if this is really the error condition I've been seeing on previous occasions. I'm restarting now with Thunderbird launched as I used to, from the dock, and will see how that goes...

This was the first hang in about a week; seemed to be same symptoms as usual, however I'd started Thunderbird from the Dock instead of command-line this time (as opposed to the last two backtraces I posted). Also, this was under MacOS 10.6.6, the latest update. Once again, after connecting with gdb, I did "thread apply all bt" to get the posted file. Then type 'cont' as TB seemed to have stopped, and gdb didn't respond at all until I hit "Quit" from the dock, and then thunderbird quit nicely. When I started it up again a few seconds later there was no hang and within a few seconds I had all the missing mail. Is there some other diagnostic that would be helpful here?

JNIEnv seems to be related to java - do you have any extensions or plugins that use java?

David - as I mentioned earlier, I have no extensions or plugins installed in my Thunderbird setup. If I click on Preferences -> General -> Manage Add-Ons, and select Plugins or Extensions tabs, those are completely empty. I don't know why JNIEnv shows up in the backtrace - it's in several threads. But it's there even when TB is working fine (I just did a gdb attach/backtrace on a working instance and it had several threads with JNIEnv mentioned). I had another hang this morning by the way - same scenario as other recent instances.

I finally had this happen again this time with the 100% CPU problem. Thunderbird appeared to be failing in the same manner as the last few times - trying to connect to the same SSL IMAP mailbox, but this time when I went to the Dock entry and moused over to "Quit", it did close all thunderbird windows, and seems to have closed about half of its threads, but it got stuck, and hit 100% CPU for several minutes. I then attached gdb and did the "thread apply all bt" to get the attached backtrace.

There doesn't seem to be anything mailnews related in those stacks, but the stacks are a bit strange so I wonder if the symbols are really right.

This just happened a second time today with the 100% cpu problem; backtrace attached again. It's almost the same as the last one except for an additional Thread 8 (doing start_wqthread) and some details in Thread 1. Looks like maybe an infinite loop in "std::__adjust_heap" ??

I wonder if asuth has any idea what these stack traces could mean...

The resolved names in the stacks are no good; the build does not have enough symbols. I'm unclear if the addresses in the backtraces are sufficiently normalized that we can use the symbol server to re-resolve them after the fact, but the easiest thing is to start providing builds with the delicious symbols that Shark and gdb crave. I have filed bug 629215 to get them turned back on.

It turns out that we already have builds with symbols! apsmith, I've created a wiki page here: https://wiki.mozilla.org/Thunderbird:Backtraces_On_OS_X that covers how to get a build with symbols or get symbols for the build you already have. If you experience any problems getting a build or if the page turns out to be wrong, please update the wiki page if you know what is wrong/how to fix it, or please mention it here if you do not know how to fix it.

Ok, I've downloaded the 3.3 development build, will see if this recurs and get a backtrace in that case.

The attached is a backtrace obtained from a nightly Shredder build as mentioned in an earlier comment here - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110127 Thunderbird/3.3a3pre Circumstances - again this time Shredder hung trying to download messages for one mailbox, I hit the 'x' on the mail window to close it, then "Quit" from the dock preparing to restart. The Shredder binary refused to quit, although it also did *not* go to 100% cpu as in previous instances. Backtrace was obtained at this point where it was refusing to quit (had to Force Quit to get it to stop).

Ok, this last one may be more helpful - finally I'm seeing IMAP stuff in the backtrace. I had another hang on arriving at work this morning; both mailboxes were spinning this time. I left them for at least 10 minutes, then attached gdb and did a "thread apply all bt" with this result. Still not sure this is doing what you need though to see what the problem is... By the way, when gdb starts up on shredder it goes through a long list of "warning: Could not find object file "/builds/slave/macosx64-comm..."

That shows imap thread alive but not blocked. So you weren't shutting down, it was just hung when you arrived?

Yes - the difference between this backtrace and the last one was that in the last one (the attachment dated 2011-01-30) I clicked "Quit" before attaching gdb and getting the backtrace; this time I got the backtrace before hitting "Quit". In both cases the behavior as far as user experience was identical and almost the same as in the Thunderbird (non-Shredder) cases I posted earlier. After waking laptop from sleep and opening a mail window, it appeared to be stuck in downloading mail (circle icon twirling) but no mail appeared after many minutes. Closing and opening the mailbox window, selecting different mailbox lines, etc. had no effect. Hitting Quit resulted in a hang, requiring a Force-Quit to actually kill it. I did a back trace after Quit this time also and it was almost identical to the last one, so I didn't post. After restart, everything was fine again (lots of mail appeared within a few seconds).

Yeah, these backtraces are still giving up really early, presumably because of -fomit-frame-pointer. If there's a deadlock/livelock happening, we can't see it. You'll either need to get the symbols from the nightly (the alternate option I listed on the link I posted: https://wiki.mozilla.org/Thunderbird:Backtraces_On_OS_X) or we need to figure out how to tell gdb to use better stack-walking heuristics that do not fall down so easily. That might require a more modern gdb or the like.

fetch-symbols.py failed on Shredder 3.3a3pre (404 error) but I was able to run it for the 3.1.7 Thunderbird I had previously been seeing the problem with, so I'm back to using that. I attached with gdb while it was running normally and got this latest backtrace - can you verify this is the sort of thing you're looking for? I still see nothing about IMAP here...

It appears the script actually did not work at all for Thunderbird... your stacks still have bad guesses as a result. My apologies; I was off-site and did not have access to my OS X box on which I actually could have tested things myself. I have updated the wiki page, but here is also a direct link to a script that actually works: http://hg.mozilla.org/users/bugmail_asutherland.org/opc-fetch-symbols/raw-file/tip/fetch-symbols.py It works for both 3.1.7 and 3.3.x nightlies, but you are going to want to stick with 3.1.7 for gdb. The stack unwinding for gdb still gives up way too early on 3.3.x. Shark / "Sample Process" from the Activity Manager does not seem to have the same problem though. If you are getting the 100% usage case, I'd suggest using Shark / "Sample Process" instead of gdb, but for a deadlock (0% CPU or very low and not quitting), I'd go with gdb... This is what success should look like on 3.1.7: Fetching symbol index http://symbols.mozilla.org/thunderbird/thunderbird-3.1.7-Darwin-20101207114001-symbols.txt Skipping Thunderbird.dSYM.tar.bz2 (no corresponding binary) libfreebl3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libfreebl3.dylib.dSYM.tar.bz2 libldap60.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libldap60.dylib.dSYM.tar.bz2 libldif60.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libldif60.dylib.dSYM.tar.bz2 libmozjs.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libmozjs.dylib.dSYM.tar.bz2 libnspr4.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libnspr4.dylib.dSYM.tar.bz2 libnss3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libnss3.dylib.dSYM.tar.bz2 libnssckbi.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libnssckbi.dylib.dSYM.tar.bz2 libnssdbm3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libnssdbm3.dylib.dSYM.tar.bz2 libnssutil3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libnssutil3.dylib.dSYM.tar.bz2 libplc4.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libplc4.dylib.dSYM.tar.bz2 libplds4.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libplds4.dylib.dSYM.tar.bz2 libprldap60.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libprldap60.dylib.dSYM.tar.bz2 libsmime3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libsmime3.dylib.dSYM.tar.bz2 libsoftokn3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libsoftokn3.dylib.dSYM.tar.bz2 libsqlite3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libsqlite3.dylib.dSYM.tar.bz2 libssl3.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libssl3.dylib.dSYM.tar.bz2 libxpcom.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libxpcom.dylib.dSYM.tar.bz2 libxpcom_core.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/libxpcom_core.dylib.dSYM.tar.bz2 thunderbird-bin.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin.dSYM.tar.bz2 libalerts_s.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/components/libalerts_s.dylib.dSYM.tar.bz2 libjsd.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/components/libjsd.dylib.dSYM.tar.bz2 libxpinstall.dylib.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/components/libxpinstall.dylib.dSYM.tar.bz2 crashreporter.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/crashreporter.app/Contents/MacOS/crashreporter.dSYM.tar.bz2 updater.dSYM.tar.bz2 -> /Applications/Thunderbird.app/Contents/MacOS/updater.app/Contents/MacOS/updater.dSYM.tar.bz2 Done.

Looks like symbols are there now! I guess we've been wasting time up to this point. This is a backtrace from gdb attach with "thread apply all bt" on 3.1.7 after using Andrew's latest fetch-symbols.py script. So, I hope this is what you're looking for. I'll sit tight and wait for the next hang and post that backtrace as soon as I see it. Thanks.

Thx for your persistance! Those stacks look much more in depth, but they don't show any blocked imap threads (the previous stacks actually had enough depth that they also showed the imap threads weren't blocked). But they do show imap threads active, which is odd on shutdown. If you turn off expunge inbox on exit, does it help? An imap protocol log of a session where you shutdown and see this bug might be informative - https://wiki.mozilla.org/MailNews:Logging - particularly, the tail end of the log where we should be trying to log you out of your connections on shutdown.

FWIW, I quite often see imap hanging during normal operations now, and then it won't shut down, and I kill it. That's on an zimbra IMAP server, with three inboxes marked as "check for new mail". Usually the check for the main inbox is turning the little throbber on, but doesn't get anywhere.

(In reply to comment #110) > Thx for your persistance! Those stacks look much more in depth, but they don't > show any blocked imap threads (the previous stacks actually had enough depth > that they also showed the imap threads weren't blocked). But they do show imap > threads active, which is odd on shutdown. Sorry if I wasn't clear, but this latest one was *not* from a shutdown case, it was from Thunderbird just running normally, to verify I was seeing the symbols properly now. I don't have a reproducible way to trigger the hang, just have to wait for it to happen again and I'll post backtraces from that then.

Here's a stack trace from a nightly build, including symbols. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15pre) Gecko/20110207 Lightning/1.0b2 Lanikai/3.1.9pre

looks to be an attempt to run an imap url too late in the shutdown process. Do you still have expunge inbox on exit set to true? Generating an imap protocol log of a session where you hang on shutdown could be helpful - https://wiki.mozilla.org/MailNews:Logging - the tail end of the log would be the interesting part.

(In reply to comment #114) > looks to be an attempt to run an imap url too late in the shutdown process. Do > you still have expunge inbox on exit set to true? Where is that setting hiding?

account settings, server settings, toward the bottom right hand corner of the dialog.

Disabled, on both accounts

(In reply to comment #117) > Disabled, on both accounts It was already disabled, or you just disabled it? I only ask because, in an earlier comment, you said it was turned on...

oh, sorry, that wasn't you... never mind :-)

(In reply to comment #119) > oh, sorry, that wasn't you... never mind :-) :) Nope, wasn't me. I have never had that turned on.

and log file for attachment 511914 [details]

have been trying to reproduce for a while. Here's a gdb stack trace, with symbols. TBird running for a while, multiple sleep cycles, hit quit, then hangs.

here's the tail end of my imap log for the above stack trace

(In reply to comment #124) and no, I never use expunge at exit.

Thx for the logs. Both logs show us doing folder status on a bunch of folders, and then shutting down our imap connections. The logs don't show us trying to run a new url, but the stack traces both show an imap thread establishing a connection to the server, while the main thread is in shutdown mode. I don't know if nspr logging gets shut down too early at shutdown time, though that seems unlikely. We try to prevent IMAP urls from getting run once shutdown starts and shutdown has clearly started from the protocol log. So I'm at a bit of a loss. It's good that both of you seem to be experiencing the same issue, though.

I'm seeing this intermittently too, and will see if I manage to create a debug build and reproduce in debugger. Please excuse me if I'm stating something obvious or missing something, but I have a feeling that the shutdown hang is a symptom of something going wrong earlier on, for instance the IMAP url might be already running upon shutdown and preventing other requests or shutdown from being executed. Being unable to fetch new mail before trying to shut down would support this.

(In reply to comment #127) > Please excuse me if I'm stating something obvious or missing something, but I > have a feeling that the shutdown hang is a symptom of something going wrong > earlier on, for instance the IMAP url might be already running upon shutdown > and preventing other requests or shutdown from being executed. Being unable to > fetch new mail before trying to shut down would support this. That's possible, and a more complete log would tell us for sure if that's the case. But, we do have timeouts in the netwerking code, so in theory, an earlier request should timeout eventually. I know I've seen similar symptoms when autosync is running full bore on a new profile and I try to exit the app.

Some new observations from me: 1. Since I switched my mailserver (Dovecot) from mbox to Maildir just before newyear, the frequency of occurence has dropped dramatically. Before, it happened few times a week. Now, it has happened 3 or 4 times in 6 weeks. Maybe (but this is just my guessing) the server is now more responsive, thereby reducing the window of opportunity to put the mac to sleep at the "wrong" time? 2. Last two times I got the spinning disk after waking my iMac from sleep, I moved and deleted some e-mail. After that, the spinning disc disappeared, and new mail arrived to my inbox. Again guessing, could it be that some ongoing action is cancelled in order to do the move/delete in this case? Off course, I could also be looking at a completely different spinning disc problem now... And some more guesswork w.r.t. the timeout mentioned before: could it be that due to the mac going through a sleep/wake cycle, that timeouts and checks on timeouts somehow get screwed up (e.g. timer values gone past their wraparound after wakeup, or not getting proper value yet from some system call early in the wakeup), thereby getting much longer timeout than expected on something that started before the sleep and continues after wakeup?

FWIW, the couple times I saw this happen, I was setting up a new machine with an existing gmail account, and letting it do autosync. After I let it sync for 30 minutes or so, I shut down the app, and it hung on shutdown. I did the same thing again, and had the same hang on shutdown. So then I started going offline before shutting down, and didn't have a problem. I've been trying to reproduce this w/o any success. My network has been awful today, with the connection going down all day long, and I haven't seen a hang on shutdown. My gut feeling is that the longer you leave Thunderbird running, the longer it takes to shutdown, and the more chance there is for mischief. But trying to reproduce that is *not* easy.

It's hard to say for sure, but I'd guess at least a full day is required runtime for this problem to occur for me. The longer TB is running beyond that, the more likely. I can't say that computer sleeping is required, but it's inevitable for the computer to sleep when it's been running that long. Also, I got another hang before, and the only difference was that the number of threads stuck in the imap code was 10 instead of 4 in my earlier hang, otherwise the stack was the same. I'd guess TB was running for longer this time, but I don't know exactly.

I have not been able to reproduce the reported bug condition here for several weeks, when starting from the command-line (which seems to be the only way symbols work). I have seen the frozen-100% CPU problem when starting Thunderbird from the Dock, but only once in the past few weeks. So something seems different. In any case, I do regularly see hangs, and I've attached a backtrace from one of them. But it's different from the "high cpu" state this bug is ostensibly about - TB happily just quits without needing a kill -9 or anything in this state for me right now (as of recent weeks). The hang is still quite annoying though.

I just got a stalled "save as draft" in one email, and the next email failed to save as a draft, too. Sadly, I hit this about daily at this point in time, it's increasingly often the more "check for new emails" folders I have.

Axel, does "stalled "save as draft"" mean you are hung as in UI stops reponding? If so, your issue is not this bug. Perhaps more likely bug 482811.

Ya know guys I hate to say this, (and this is very preliminary), but since I don't see any comments here saying something has been fixed... Since I updated to the latest rev of Little Snitch (2.3.4), I havent had a hang yet when running the updater on the nightlies.

So I guess it's time to report... I've been running in debugger for a couple of weeks now and finally got something that might be of interest, though does not fit in the "no imap connections" part of the summary: Opening a folder seemed to stall so I paused it in the debugger and took a look of the threads. I found an imap thread hung waiting for a line from the server. Call stack: #0 0x7fff8766afca in __semwait_signal #1 0x7fff8766ede1 in _pthread_cond_wait #2 0x105517144 in PR_WaitCondVar at ptsynch.c:417 #3 0x1055178c3 in PR_Wait at ptsynch.c:614 #4 0x10015057d in nsAutoMonitor::Wait at nsAutoLock.h:346 #5 0x10194a468 in nsPipeInputStream::Wait at nsPipe3.cpp:653 #6 0x10194bbca in nsPipeInputStream::ReadSegments at nsPipe3.cpp:778 #7 0x1019491c1 in nsPipeInputStream::Read at nsPipe3.cpp:827 #8 0x10148095c in nsMsgLineStreamBuffer::ReadNextLine at nsMsgLineBuffer.cpp:403 #9 0x10172eb81 in nsImapProtocol::CreateNewLineFromSocket at nsImapProtocol.cpp:4737 #10 0x101740e7e in nsImapProtocol::EstablishServerConnection at nsImapProtocol.cpp:1473 #11 0x101745d6d in nsImapProtocol::ProcessCurrentURL at nsImapProtocol.cpp:1646 #12 0x101737880 in nsImapProtocol::ImapThreadMainLoop at nsImapProtocol.cpp:1401 #13 0x10173ee42 in nsImapProtocol::Run at nsImapProtocol.cpp:1097 #14 0x10197ad9a in nsThread::ProcessNextEvent at nsThread.cpp:633 #15 0x101904532 in NS_ProcessNextEvent_P at nsThreadUtils.cpp:250 #16 0x10197b824 in nsThread::ThreadFunc at nsThread.cpp:278 #17 0x10551e0fb in _pt_root at ptthread.c:187 #18 0x7fff87669536 in _pthread_start #19 0x7fff876693e9 in thread_start So it seems it thought it had an open socket but hadn't received the greeting from the server. Apparently A) the server had sent it but it has been lost B) the server had sent it but the IMAP_RECEIVED_GREETING flag has been lost or C) the server hadn't sent the greeting. m_flags in nsImapProtocol was 4. I had it paused in the debugger for so long that the wait timed out and normal operation resumed. But perhaps this combined with something else happening at the same time could cause trouble? A long shot, maybe, but might give a clue. Perhaps it would be useful to check how long a connection has been in opened state without receiving IMAP greeting before trying to use it? By the way, it just occurred to me that used to have a lot more trouble with Thunderbird when I had a router with a very short NAT timeout that caused idle connections to silently become unroutable.

One more thing: unfortunately I forgot to enable protocol logging before encountering the above situation..

Just encountered this problem again, and did a little experiment. Instead of quiting TB, I set the time of my iMac back 2 minutes. After that, the spinning disc disappeared and e-mail arrived in my Inbox again. Putting time back to automatic and everything seems fine now. This was just a one time try, but if others can repeat this little experiment this may hint to some faulty timeout handling.

(In reply to comment #135) > Ya know guys I hate to say this, (and this is very preliminary), but since I > don't see any comments here saying something has been fixed... Since I updated > to the latest rev of Little Snitch (2.3.4), I havent had a hang yet when > running the updater on the nightlies. Interesting. Have you tried rolling back to the previous version to confirm the theory?

(In reply to comment #136) > So I guess it's time to report... I've been running in debugger for a couple of > weeks now and finally got something that might be of interest, though does not > fit in the "no imap connections" part of the summary: actually it does. "no imap connection" in the summary refers to netstat not showing an imap connection. (comment 46) [as compared to bug 535822, where netstat does show connections]

(In reply to comment #139) > (In reply to comment #135) > > Ya know guys I hate to say this, (and this is very preliminary), but since I > > don't see any comments here saying something has been fixed... Since I updated > > to the latest rev of Little Snitch (2.3.4), I havent had a hang yet when > > running the updater on the nightlies. > > Interesting. Have you tried rolling back to the previous version to confirm the > theory? Hi Wayne, well it still happens. I have the vaguest feeling it happens less. However this is based on that sometimes lankai will then quit when it pulls down an update and i restart it. However there are times that it still hangs. If it is related its not direct. Also I allow LS to allow any kind of connections lankai wants.

The attached log shows a weird error situation that I encountered right after wakeup from sleep. I'm reporting it because it might be related, and would indicate something going wonky in the socket code. How it manifested itself was that I clicked the Get Mail button or selected the inbox of the gmail account (can't remember which one, but probably the latter), and instead of opening the inbox TB complained that the login failed. I chose to retry and then it worked fine.

(In reply to comment #142) > Created attachment 523661 [details] > Log of weird stuff happening right after wakeup > > The attached log shows a weird error situation that I encountered right after > wakeup from sleep. I'm reporting it because it might be related, and would > indicate something going wonky in the socket code. How it manifested itself was > that I clicked the Get Mail button or selected the inbox of the gmail account > (can't remember which one, but probably the latter), and instead of opening the > inbox TB complained that the login failed. I chose to retry and then it worked > fine. We're getting a timeout error trying to logon, which we're interpreting as an auth failure. We were able to connect to the server, and then the connection timed out during auth, which is a bit odd.

(In reply to comment #143) > We're getting a timeout error trying to logon, which we're interpreting as an > auth failure. We were able to connect to the server, and then the connection > timed out during auth, which is a bit odd. Indeed, and what I failed to mention is that it all happened in a second or so. I've now turned on timestamping and logging of everything in the hopes that it would reveal something deeper inside.

(In reply to comment #138) > Just encountered this problem again, and did a little experiment. Instead of > quiting TB, I set the time of my iMac back 2 minutes. After that, the spinning > disc disappeared and e-mail arrived in my Inbox again. Putting time back to > automatic and everything seems fine now. > > This was just a one time try, but if others can repeat this little experiment > this may hint to some faulty timeout handling. I just encountered another spinning disk and the inbox not updating after waking up my iMac. Tried the same trick, with same result: as soon as the new time was set, new mail arrived. Any one else tried this with same or different results?

I haven't been able to reproduce this lately, probably just been (un)lucky. I started thinking maybe we should just observe sleep-notification and shut down all connections, and not rely on them timing out on wakeup. This might alleviate the issue, and to me it sounds like it would be the right thing to do anyway.

Got this again today, unfortunately not with a debug build. Observations: Logging these: IMAP:4,SMTP:4,nsStreampPump:4,clock:4,cmon:4,io:4,mon:4,cvar:4,sched:4,thread:4,nsThread:4,nsTimerImpl:4,nsEventQueue:4,negotiateAuth:4,pipnss:4,MsgBiff:4,MsgPurge:4,ImapAutoSync:4,timestamp - The folder was connected and IDLE when system went to sleep - On wakeup the connection was dropped, but courteously DONE and logout were still sent (to the closed socket) - A new connection was initiated before the old ImapThreadMainLoop exited - The new connection failed in DNS lookup - The last message the new protocol instance wrote to log was [...] NA:ProcessCurrentURL [...] = currentUrl - Selecting the folder in the UI displayed spinner, no log entries were written - Over three hours later marking a message in the folder read created a new connection and updated the folder - No hang on shutdown

(In reply to comment #146) > I started thinking maybe we should just observe sleep-notification and shut > down all connections, and not rely on them timing out on wakeup. This might > alleviate the issue, and to me it sounds like it would be the right thing to do > anyway. Yeah, that sounds right - but is there an actual mozilla sleep notification? I'll poke around.

(In reply to comment #148) > Yeah, that sounds right - but is there an actual mozilla sleep notification? > I'll poke around. Yes, there is, and according to logging I did previously it's fired as expected. It's used at least in the download manager. See: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/nsDownloadManager.cpp#902 http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/nsDownloadManager.cpp#1997

thx, I searched for sleep-notification, not _

Sorry, my mistake. Additionally, it would probably make sense to delay biff upon wakeup just like the download manager delays resumption of downloads to avoid trouble with network connections not fully established yet.

(In reply to comment #151) > Sorry, my mistake. Nah, I'd blame the person who made those notification names different from the normal ones :-) > Additionally, it would probably make sense to delay biff > upon wakeup just like the download manager delays resumption of downloads to > avoid trouble with network connections not fully established yet. Also an excellent idea - I can look into that.

Ugh, I hope you're not on Linux, because I don't see us sending a sleep notification on linux.

True, it seems to be missing. But I'm on Mac and looking at the code it should work for Windows too. Perhaps on Linux the widget code could use dbus service org.freedesktop.UPower to do the same.

I have a trivial patch for the first part of this (closing cached connections on a sleep notification) but I haven't had time to test that we get the sleep notification before sleep, via timestamps in the protocol log.

I'd gladly test the patch on Mac where I've tested that the sleep notification indeed works properly using a timestamped log.

great, thx, I have a patch that cancels biff on sleep and adds a 10 second delay to starting biff after waking up. I also verified that sleep notification and closing cached connections does indeed happen before we go to sleep. I'm just doing a rebuild, but I'll attach the patch once it's done.

this is untested by me, but is fairly straightforward.

Comment on attachment 530741 [details] [diff] [review] patch to closed connections on sleep, and delay biff restart for 10 seconds after wake Ere, I verified that biff does indeed get restarted after waking up, so I think this is ready for review - since you're going to the trouble of running with the patch, and it's very straightforward, I hope you don't mind me asking for a review while you're at it.

No problem, I'll do it tomorrow.

Comment on attachment 530741 [details] [diff] [review] patch to closed connections on sleep, and delay biff restart for 10 seconds after wake Beautiful, works just as expected and avoids the flurry of socket errors and confusion on wakeup. r=me

I think I'll still try to get the original issue to happen with a debug build so I could pinpoint the exact position where it fails.

fix checked in - http://hg.mozilla.org/comm-central/rev/fd5e010d3e0f

I have been using Thunderbird 5.0b1 and it seems to work awesome. Thanks !

Well I have good news and bad news, using 5.0b1 certainly does fix the runaway cpu issue, sadly however the app still can hang when trying to quit after sleep cycles. How can I correctly provide info here? Thx

This is indeed not fixed :( Thunderbird still hangs on quit for me. I'm guessing the root cause is the same.... Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0

I haven't had a single hang since I switched to builds containing the fix, thus no chance to try to find the cause either.

Lint, Alan, the bug has a patch and is marked FIXED, so it won't be reopened (as is almost always the case). You should therefor consult comment 83 and file a new bug report if needed. If you file a new bug, post the number here.

I posted in several getsatisfaction topics that some fixing has occurred. including http://getsatisfaction.com/mozilla_messaging/tags/sleep feedback has been limited, but all positive. The patch in this bug is OS=ALL. But it is unclear whether any windows users experience this issue. Bienvenu notes for example, that windows shutdown is different from Mac. Remaining shutdown hang bugs are https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&keywords=hang&keywords_type=allwords&short_desc=%20exit%20shut%20sleep%20quit%20wake%20waki%20hiber&field0-0-0=short_desc&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&short_desc_type=anywordssubstr&type0-0-0=anywordssubstr&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc&list_id=930758