Closed
Bug 508263
Opened 15 years ago
Closed 13 years ago
3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry after sleep/wake. fixed by closing cached imap connections on sleep, and delay biff restart. mostly or all Mac
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 5.0b1
People
(Reporter: allan, Assigned: Bienvenu)
References
()
Details
(Keywords: hang, Whiteboard: [see comment 83 before commenting] [gs][gssolved])
Attachments
(17 files, 13 obsolete files)
38.54 KB,
text/plain
|
Details | |
4.78 KB,
text/plain
|
Details | |
11.03 KB,
application/octet-stream
|
Details | |
56.31 KB,
text/plain
|
Details | |
41.76 KB,
text/plain
|
Details | |
275.32 KB,
text/plain
|
Details | |
29.77 KB,
text/plain
|
Details | |
107.46 KB,
application/zip
|
Details | |
17.69 KB,
text/plain
|
Details | |
6.68 KB,
text/plain
|
Details | |
8.04 KB,
text/plain
|
Details | |
25.53 KB,
text/plain
|
Details | |
16.90 KB,
text/plain
|
Details | |
50.22 KB,
text/plain
|
Details | |
20.81 KB,
text/plain
|
Details | |
5.49 KB,
text/plain
|
Details | |
7.66 KB,
patch
|
emaijala+moz
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•15 years ago
|
||
Allan you are using POP or Imap ?
Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> Allan you are using POP or Imap ?
IMAPS
Assignee | ||
Comment 3•15 years ago
|
||
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).
Comment 4•15 years ago
|
||
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
Comment 5•15 years ago
|
||
bienvenu, does this gdb stack from all threads help? (I got this the same time as when I got the activity manager stack above)
Comment 6•15 years ago
|
||
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.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
Keywords: qawanted
I've seen this behaviour too, also using IMAPs. I'll attach a process trace too, but it'll be from the public build.
Comment 9•15 years ago
|
||
(In reply to comment #8)
> Created an attachment (id=393768) [details]
> Activity Monitor process sample
Seems to lack symbols too. See comment #4.
Reporter | ||
Comment 10•15 years ago
|
||
(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.
Comment 11•15 years ago
|
||
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?
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
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.
Comment 14•15 years ago
|
||
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
Reporter | ||
Comment 15•15 years ago
|
||
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.
Reporter | ||
Comment 16•15 years ago
|
||
oh, and the only compatible extension active is the Danish dictionary
Updated•15 years ago
|
Whiteboard: [need netstat results]
Comment 17•15 years ago
|
||
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.
Comment 18•15 years ago
|
||
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.
Comment 19•15 years ago
|
||
I've been testing 3.0b3, per the bug's subject line.
I'll try the nightly build instead.
Comment 20•15 years ago
|
||
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.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Keywords: qawanted
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
Comment 23•15 years ago
|
||
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
Comment 24•15 years ago
|
||
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 :)
Comment 25•15 years ago
|
||
(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 :-)
Reporter | ||
Comment 26•15 years ago
|
||
(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).
Comment 27•15 years ago
|
||
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.
Comment 28•15 years ago
|
||
(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.
Comment 29•15 years ago
|
||
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
Comment 30•15 years ago
|
||
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?
Comment 31•15 years ago
|
||
(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.
Reporter | ||
Comment 32•15 years ago
|
||
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.
Comment 33•15 years ago
|
||
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.
Comment 34•15 years ago
|
||
Running a nightly would also get you a sample with reliable symbols as we now include symbols on nightly builds.
Comment 35•15 years ago
|
||
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.
Comment 36•15 years ago
|
||
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.
Comment 37•15 years ago
|
||
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.
Summary: 3.0b3 hangs on exit → 3.0b3 hangs on exit/shutdown
Whiteboard: [need netstat results] → closeme 2009-12-20 [need netstat results]
Reporter | ||
Comment 38•15 years ago
|
||
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?
Assignee | ||
Comment 39•15 years ago
|
||
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.
Comment 40•15 years ago
|
||
Well I got a hang today, trying to drop an update. I'll attach the sample log. I hope it helps
Comment 41•15 years ago
|
||
Comment 42•15 years ago
|
||
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.
Comment 43•15 years ago
|
||
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
Summary: 3.0b3 hangs on exit/shutdown → 3.0b3 hangs on exit/shutdown with high cpu [speculation: losing the network connection/sleeping]
Whiteboard: closeme 2009-12-20 [need netstat results] → [need netstat results]
Comment 44•15 years ago
|
||
(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.
Comment 45•15 years ago
|
||
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.
Reporter | ||
Comment 46•15 years ago
|
||
(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.
Comment 47•15 years ago
|
||
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
Summary: 3.0b3 hangs on exit/shutdown with high cpu [speculation: losing the network connection/sleeping] → 3.0b3 hangs on exit/shutdown with high cpu, no imap connections [speculation: losing the network connection/sleeping]
Whiteboard: [need netstat results]
Comment 48•15 years ago
|
||
DavidB anything of interest in the provided stacks ?
Assignee | ||
Comment 49•15 years ago
|
||
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...
Comment 50•15 years ago
|
||
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.
Comment 51•15 years ago
|
||
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?
Reporter | ||
Comment 52•15 years ago
|
||
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 :)
Comment 53•15 years ago
|
||
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.
Comment 54•15 years ago
|
||
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.
Comment 55•15 years ago
|
||
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
Updated•15 years ago
|
Summary: 3.0b3 hangs on exit/shutdown with high cpu, no imap connections [speculation: losing the network connection/sleeping] → 3.0b3 hangs on exit/shutdown with high cpu, no imap connections [Mac only?} [speculation: losing the network connection/sleeping]
Comment 56•15 years ago
|
||
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.
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [needs link to a core bug]
Comment 58•15 years ago
|
||
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
Comment 59•15 years ago
|
||
Comment 60•15 years ago
|
||
Assignee | ||
Comment 61•15 years ago
|
||
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*)
Comment 62•14 years ago
|
||
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.
Comment 63•14 years ago
|
||
(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.
Updated•14 years ago
|
Whiteboard: [needs link to a core bug] → [needs link to a core bug] [gs]
Comment 65•14 years ago
|
||
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
Comment 66•14 years ago
|
||
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....
Comment 67•14 years ago
|
||
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.
Updated•14 years ago
|
Summary: 3.0b3 hangs on exit/shutdown with high cpu, no imap connections [Mac only?} [speculation: losing the network connection/sleeping] → 3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry [Mac only?} [speculation: losing the network connection/sleeping]
Comment 68•14 years ago
|
||
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?
Comment 69•14 years ago
|
||
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.
Comment 70•14 years ago
|
||
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
Comment 71•14 years ago
|
||
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.
Updated•14 years ago
|
Attachment #392489 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #393768 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #411302 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #438695 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #438696 -
Attachment is obsolete: true
Comment 72•14 years ago
|
||
(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.
Reporter | ||
Comment 73•14 years ago
|
||
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
Comment 74•14 years ago
|
||
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.
Comment 75•14 years ago
|
||
(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.
Comment 76•14 years ago
|
||
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)
Comment 77•14 years ago
|
||
(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
Comment 78•14 years ago
|
||
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
Comment 79•14 years ago
|
||
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.
Comment 80•14 years ago
|
||
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
Assignee | ||
Comment 81•14 years ago
|
||
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).
Comment 82•14 years ago
|
||
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?
Comment 83•14 years ago
|
||
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
Whiteboard: [needs link to a core bug] [gs] → [see comment 83 before commenting/posting] [needs link to a core bug] [gs]
Comment 84•14 years ago
|
||
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.
Comment 85•14 years ago
|
||
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.
Assignee | ||
Comment 86•14 years ago
|
||
I don't see any imap threads (or ldap threads - do you use ldap auto complete?) in those backtraces.
Comment 87•14 years ago
|
||
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.
Comment 88•14 years ago
|
||
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?
Assignee | ||
Comment 89•14 years ago
|
||
(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.
Summary: 3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry [Mac only?} [speculation: losing the network connection/sleeping] → 3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry [Mac only?] [speculation: losing the network connection/sleeping]
Reporter | ||
Comment 90•14 years ago
|
||
I do not use LDAP, and I'm always on the same network
Comment 91•14 years ago
|
||
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...
Comment 92•14 years ago
|
||
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?
Assignee | ||
Comment 93•14 years ago
|
||
JNIEnv seems to be related to java - do you have any extensions or plugins that use java?
Comment 94•14 years ago
|
||
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.
Comment 95•14 years ago
|
||
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.
Assignee | ||
Comment 96•14 years ago
|
||
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.
Comment 97•14 years ago
|
||
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" ??
Assignee | ||
Comment 98•14 years ago
|
||
I wonder if asuth has any idea what these stack traces could mean...
Comment 99•14 years ago
|
||
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.
Comment 100•14 years ago
|
||
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.
Comment 101•14 years ago
|
||
Ok, I've downloaded the 3.3 development build, will see if this recurs and get a backtrace in that case.
Comment 102•14 years ago
|
||
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).
Assignee | ||
Updated•14 years ago
|
Attachment #508313 -
Attachment mime type: application/octet-stream → text/plain
Comment 103•14 years ago
|
||
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..."
Assignee | ||
Comment 104•14 years ago
|
||
That shows imap thread alive but not blocked.
So you weren't shutting down, it was just hung when you arrived?
Comment 105•14 years ago
|
||
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).
Comment 106•14 years ago
|
||
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.
OS: Mac OS X → Windows 7
Updated•14 years ago
|
OS: Windows 7 → Mac OS X
Comment 107•14 years ago
|
||
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...
Comment 108•14 years ago
|
||
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.
Updated•14 years ago
|
Attachment #508734 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #508373 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #508313 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #507272 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #507116 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #503477 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #501976 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #501214 -
Attachment is obsolete: true
Comment 109•14 years ago
|
||
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.
Assignee | ||
Comment 110•14 years ago
|
||
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.
Comment 111•14 years ago
|
||
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.
Comment 112•14 years ago
|
||
(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.
Reporter | ||
Comment 113•14 years ago
|
||
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
Assignee | ||
Comment 114•14 years ago
|
||
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.
Reporter | ||
Comment 115•14 years ago
|
||
(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?
Assignee | ||
Comment 116•14 years ago
|
||
account settings, server settings, toward the bottom right hand corner of the dialog.
Reporter | ||
Comment 117•14 years ago
|
||
Disabled, on both accounts
Assignee | ||
Comment 118•14 years ago
|
||
(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...
Assignee | ||
Comment 119•14 years ago
|
||
oh, sorry, that wasn't you... never mind :-)
Reporter | ||
Comment 120•14 years ago
|
||
(In reply to comment #119)
> oh, sorry, that wasn't you... never mind :-)
:) Nope, wasn't me. I have never had that turned on.
Reporter | ||
Comment 121•14 years ago
|
||
Reporter | ||
Comment 122•14 years ago
|
||
and log file for attachment 511914 [details]
Comment 123•14 years ago
|
||
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.
Comment 124•14 years ago
|
||
here's the tail end of my imap log for the above stack trace
Comment 125•14 years ago
|
||
(In reply to comment #124)
and no, I never use expunge at exit.
Assignee | ||
Comment 126•14 years ago
|
||
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.
Comment 127•14 years ago
|
||
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.
Assignee | ||
Comment 128•14 years ago
|
||
(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.
Comment 129•14 years ago
|
||
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?
Assignee | ||
Comment 130•14 years ago
|
||
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.
Comment 131•14 years ago
|
||
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.
Comment 132•14 years ago
|
||
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.
Comment 133•14 years ago
|
||
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.
Comment 134•14 years ago
|
||
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.
Comment 135•14 years ago
|
||
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.
Comment 136•14 years ago
|
||
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.
Comment 137•14 years ago
|
||
One more thing: unfortunately I forgot to enable protocol logging before encountering the above situation..
Comment 138•14 years ago
|
||
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.
Comment 139•14 years ago
|
||
(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?
Comment 140•14 years ago
|
||
(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]
Comment 141•14 years ago
|
||
(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.
Comment 142•14 years ago
|
||
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.
Assignee | ||
Comment 143•14 years ago
|
||
(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.
Comment 144•14 years ago
|
||
(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.
Comment 145•13 years ago
|
||
(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?
Comment 146•13 years ago
|
||
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.
Comment 147•13 years ago
|
||
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
Assignee | ||
Comment 148•13 years ago
|
||
(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.
Comment 149•13 years ago
|
||
(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
Assignee | ||
Comment 150•13 years ago
|
||
thx, I searched for sleep-notification, not _
Comment 151•13 years ago
|
||
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.
Assignee | ||
Comment 152•13 years ago
|
||
(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.
Assignee | ||
Comment 153•13 years ago
|
||
Ugh, I hope you're not on Linux, because I don't see us sending a sleep notification on linux.
Comment 154•13 years ago
|
||
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.
Assignee | ||
Comment 155•13 years ago
|
||
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.
Comment 156•13 years ago
|
||
I'd gladly test the patch on Mac where I've tested that the sleep notification indeed works properly using a timestamped log.
Assignee | ||
Comment 157•13 years ago
|
||
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.
Assignee | ||
Comment 158•13 years ago
|
||
this is untested by me, but is fairly straightforward.
Assignee: nobody → dbienvenu
Assignee | ||
Comment 159•13 years ago
|
||
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.
Attachment #530741 -
Flags: review?(emaijala)
Comment 160•13 years ago
|
||
No problem, I'll do it tomorrow.
Comment 161•13 years ago
|
||
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
Attachment #530741 -
Flags: review?(emaijala) → review+
Comment 162•13 years ago
|
||
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.
Assignee | ||
Comment 163•13 years ago
|
||
fix checked in - http://hg.mozilla.org/comm-central/rev/fd5e010d3e0f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
Comment 164•13 years ago
|
||
Comment 165•13 years ago
|
||
I have been using Thunderbird 5.0b1 and it seems to work awesome. Thanks !
Comment 166•13 years ago
|
||
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
Reporter | ||
Comment 167•13 years ago
|
||
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
Comment 168•13 years ago
|
||
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.
Comment 169•13 years ago
|
||
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.
Comment 170•13 years ago
|
||
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
Keywords: qawanted
OS: Mac OS X → All
Summary: 3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry [Mac only?] [speculation: losing the network connection/sleeping] → 3.0b3 hangs on exit/shutdown with high cpu, no imap connections, no ldap connection or stack entry after sleep/wake. fixed by closing cached imap connections on sleep, and delay biff restart. mostly or all Mac
Whiteboard: [see comment 83 before commenting/posting] [needs link to a core bug] [gs] → [see comment 83 before commenting] [gs][gssolved]
You need to log in
before you can comment on or make changes to this bug.
Description
•