thunderbird uses 100% CPU and doesn't terminate if quit during connection
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Thunderbird |
Fix Released
|
Critical
|
|||
thunderbird (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
I have the same problem: TB consumes almost 100% of one core all the time.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
uname -a: Linux golem 2.6.32-
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
############
Binary package hint: thunderbird
If I quit thunderbird normally while in the 'looking up' or other stage of connecting to a mail server, the process does not terminate, and thunderbird-bin uses 100% CPU on waiting channel 0.
natty
thunderbird 3.1.7+build3+
uname Linux delan1 2.6.37-8-server #21-Ubuntu SMP Sun Dec 5 18:13:15 UTC 2010 x86_64 GNU/Linux
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #3 |
In Mozilla Bugzilla #565065, Bugmail-asutherland (bugmail-asutherland) wrote : | #4 |
strace output is not super useful unless you also happened to do an "ls -l /proc/4156/fd" and logged it. Most useful would be stack traces via gdb or 'perf' although I must concede I'm not clear on where the debug symbols for official linux builds end up... one would ideally have that already installed and available so those tools could use them. If there's a way to kill it to get breakpad to report it, that might also work...
In Mozilla Bugzilla #565065, Vseerror (vseerror) wrote : | #5 |
protz, adding critical + hang. you can add hang keyword when creating the bug if you do "Show Advanced Fields" on the bug entry form.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #6 |
I just managed to reproduce the bug! I also managed to kill the process using a SIGSEGV. That triggered breakpad and I submitted a crash report.
bp-
Plus, I also did ls -l and a strace -p. The files are here.
http://
And the crash report is there.
http://
It might be an extension, but it's hard to tell.
In Mozilla Bugzilla #565065, Bugmail-asutherland (bugmail-asutherland) wrote : | #7 |
bienvenu, you'll probably want to look at this crash report. It looks like nsMsgCompressIS
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #8 |
protz, are you using the fastmail imap server, or an other imap server that supports compress? You can try toggling mail.server.
Do you have empty trash/expunge inbox on exit set? I wonder if this is some failure to connection problems in the decompress code...
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #9 |
(In reply to comment #5)
> protz, are you using the fastmail imap server, or an other imap server that
> supports compress? You can try toggling
> mail.server.
>
How can I know if a IMAP server supports deflate? One is imap.googlemail
jonathan@nala:~ $ nc imap.ens-lyon.fr 143
* OK bubulcus Cyrus IMAP4 v2.2.13-
^C
jonathan@nala:~ $ nc imap.free.fr 143
* OK [CAPABILITY IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS AUTH=LOGIN] IMAP4rev1 Free
^C
> Do you have empty trash/expunge inbox on exit set? I wonder if this is some
> failure to connection problems in the decompress code...
None of my accouts has this setting.
It's kind of hard to reproduce. I'll try a tcpdump next to see which connections are still open when it loops like that. I haven't any reliable way to reproduce this.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #10 |
You'd need an imap protocol log to see what the capability response was for each server - https:/
In Mozilla Bugzilla #565065, Ludovic-mozilla (ludovic-mozilla) wrote : | #11 |
Protz can we get somewhere with this bug ?
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #12 |
Not really. For a while I exported the right environment variables when starting Thunderbird, so that I would get a protocol dump when it got stuck, but I haven't been able to reproduce it in such conditions. I don't have a reliable way to reproduce, and as I said, it's very random.
David, do you need the protocol log right when it crashes, or just the first few lines?
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #13 |
I don't need a protocol log of the getting stuck part, just the initial part of the log where we ask the server what its capabilities are. But I believe gmail has added compress/deflate support.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #14 |
Created attachment 466412
IMAP protocol log, first few seconds
Here's the log. It's not the same computer that experiences the bug, but it's the same setup for accounts.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #15 |
so yeah, that confirms that your gmail server does support COMPRESS, so that would be consistent with asuth's diagnosis. But that's only marginally helpful. I suspect this is a linux-y issue, since we have a ton of gmail users, and have not heard other reports of this.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #16 |
What can I do to help track down this issue?
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #17 |
You could try toggling
mail.server.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #18 |
It used to be ~twice a week, now I don't know, I'm using momo's mac as my primary machine :).
You can tell me which parts of logging to enable, and I'll make sure whenever I run Thunderbird on the faulty machine, these are enabled, just in case.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #19 |
IMAP:5 is where I'd start, since it tells us what's happening with server communications at shutdown, and the other forms of logging (e.g., socket transport) are too fire-hosey.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #20 |
Created attachment 466644
Hang log
I managed to reproduce the bug. Seems to happen after Tb has been open for a long time (overnight). Tb feels sluggish and unresponsive, feel like restarting it, and then the bug appears.
Tb went 100% cpu, waited ~10 seconds, and then killed it. Here's the protocol log.
In Mozilla Bugzilla #565065, Vseerror (vseerror) wrote : | #21 |
Nikolay, Jay, does anything in the imap log pop out? :)
protz, can you reasonably rule out extensions? Which ones do you run?
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #22 |
That error is NS_ERROR_ABORT, which is the status we give when trying to close the transport because the app is getting shut down. In this case, I guess a stack trace of the hang might be helpful.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #23 |
I feel like this is happening when some IMAP connection is open and my network connection is shut down (i.e. I loose the wifi connection, for instance).
I already put a crashreport in comment #3. What do you mean by stack trace? Do you want me to attach gdb to the running process and bt once it's killed? Do I need to run a debug build for this or is a shared build ok?
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #24 |
(In reply to comment #20)
> I already put a crashreport in comment #3.
Yeah, that didn't contain much useful that I could see.
> Do you want me to attach gdb to the running process and bt once it's killed?
Yes, I want to see what the threads are doing that's preventing the app from shutting down. So attach and break into the debugger.
> need to run a debug build for this or is a shared build ok?
If you can get symbols, a shared build is fine.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #25 |
Yay! Managed to get a backtrace.
Please note that the symptoms are linked to my connection being particularly crappy (mobile phone tethering) and sockets timing out. I event got a "too many imap connections for this account" error message.
After I understood that Thunderbird was not closing properly, I attached gdb to it, killed Thunderbird, and ran a backtrace. Here comes the full backtrace.
0x00007f7ea666f0bd in read () from /lib/libpthread
(gdb) bt
#0 0x00007f7ea666f0bd in read () from /lib/libpthread
#1 0x00007f7ea538cbba in nsAppShell:
source=<value optimized out>, condition=<value optimized out>,
data=
at /home/jonathan/
#2 0x00007f7ea10b86f2 in g_main_
#3 0x00007f7ea10bc568 in ?? () from /lib/libglib-
#4 0x00007f7ea10bc71c in g_main_
from /lib/libglib-
#5 0x00007f7ea53a23c7 in nsBaseAppShell:
mayWait=
at /home/jonathan/
#6 0x00007f7ea53a25b1 in nsBaseAppShell:
this=
recursionDe
at /home/jonathan/
#7 0x00007f7ea569fd11 in nsThread:
mayWait=1, result=
at /home/jonathan/
#8 0x00007f7ea566fcd1 in NS_ProcessNextE
---Type <return> to continue, or q <return> to quit---
mayWait=
#9 0x00007f7ea4b5d8e6 in nsSyncStreamLis
this=
at /home/jonathan/
#10 0x00007f7ea4b5d93a in nsSyncStreamLis
this=
at /home/jonathan/
#11 0x00007f7ea4b5d7c4 in nsSyncStreamLis
buf=
at /home/jonathan/
#12 0x00007f7ea5443293 in unsigned int NS_ReadLine<char, nsIInputStream, nsCAutoString>
from /home/jonathan/
#13 0x00007f7ea543783f in nsMsgDBFolder:
this=<value optimized out>, stream=<value optimized out>,
aCharset=<value optimized out>, bytesToRead=<value optimized out>,
aMaxOutputL
aCompressQu
aMsgText=...)
at /home/jonathan/
5
#14 0x00007f7ea56abc4a in NS_InvokeByIndex_P (that=0xf,
methodIndex
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #26 |
So that just means we're trying to get some message text for the new mail alert (most likely). It doesn't look like a hang, per se. Does linux display message text for the new mail alert?
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #27 |
I've had issues with the popup alert, yes, the most notable one being the popup flickering for a fraction of a second and not showing properly, although because I wasn't able to reliably trigger it, I never filed a bug.
I'll try to get more backtraces to see if we're always stuck in the same area.
In Mozilla Bugzilla #565065, Vseerror (vseerror) wrote : | #28 |
(In reply to comment #23)
> It doesn't look like a hang, per se. Does linux display message text for the new mail alert?
what is this, if it isn't a hang?
if it's a linux new message pop up perf issue, see Bug 367431 - New Mail alert popup takes 100% CPU for 10 secs
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #29 |
(In reply to comment #25)
>
> what is this, if it isn't a hang?
I'm just saying that stack trace doesn't look like it's hung.
In the past, we've had bugs where the code on linux and windows that's supposed to shut down the app when the last window is closed gets the count wrong, and leaves the app spinning the event loop, but no window up. And the new mail alert window might confuse that count.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #30 |
Happened again. The computer is an 8-core i7 Xeon, and I waited for 30s+ before attaching gdb, and the CPU kept going through the roof at 100% all the time, so I think it's definitely a hang. One more backtrace (not very helpful, I'm afraid).
(gdb) bt
#0 0x00007f674b4b2113 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=0)
at ../sysdeps/
#1 0x00007f674c6dd2c9 in ?? () from /lib/libglib-
#2 0x00007f674c6dd71c in g_main_
#3 0x00007f673b5dd337 in nsBaseAppShell:
at /home/jonathan/
#4 0x00007f673b5dd5cd in nsBaseAppShell:
mayWait=0, recursionDepth=
at /home/jonathan/
#5 0x00007f674f807e05 in nsThread:
at /home/jonathan/
#6 0x00007f674f7d439a in NS_ProcessNextE
#7 0x00007f674f80815f in nsThread::Shutdown (this=0x7f671b0
at /home/jonathan/
#8 0x00007f674f809058 in nsThreadManager
at /home/jonathan/
#9 0x00007f674f7d7534 in mozilla:
at /home/jonathan/
#10 0x00007f674fc94dc5 in ~ScopedXPCOMStartup (this=0x7fff00d
at /home/jonathan/
#11 0x00007f674fc984c2 in XRE_main (argc=<value optimized out>, argv=<value optimized out>,
aAppData=<value optimized out>)
at /home/jonathan/
#12 0x0000000000401b04 in main (argc=1, argv=0x7fff00dc
at /home/jonathan/
Is there anything useful you want me to do next time?
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #31 |
0x00007fda3be9f113 in *__GI___poll (fds=<value optimized out>,
nfds=<value optimized out>, timeout=0)
at ../sysdeps/
87 ../sysdeps/
in ../sysdeps/
(gdb) bt
#0 0x00007fda3be9f113 in *__GI___poll (fds=<value optimized out>,
nfds=<value optimized out>, timeout=0)
at ../sysdeps/
#1 0x00007fda3d0ca2c9 in ?? () from /lib/libglib-
#2 0x00007fda3d0ca71c in g_main_
from /lib/libglib-
#3 0x00007fda2f61b337 in nsBaseAppShell:
this=
at /home/jonathan/
#4 0x00007fda2f61b5cd in nsBaseAppShell:
this=
recursionDe
at /home/jonathan/
#5 0x00007fda401f4e05 in nsThread:
mayWait=1, result=
at /home/jonathan/
#6 0x00007fda401c139a in NS_ProcessNextE
mayWait=10) at nsThreadUtils.
#7 0x00007fda401f515f in nsThread::Shutdown (this=0x7fda27a
at /home/jonathan/
#8 0x00007fda401f6058 in nsThreadManager
---Type <return> to continue, or q <return> to quit---
at /home/jonathan/
#9 0x00007fda401c4534 in mozilla:
at /home/jonathan/
#10 0x00007fda40681dc5 in ~ScopedXPCOMStartup (this=0x7ffffc7
__in_
at /home/jonathan/
#11 0x00007fda406854c2 in XRE_main (argc=<value optimized out>,
argv=<value optimized out>, aAppData=<value optimized out>)
at /home/jonathan/
#12 0x0000000000401b04 in main (argc=1, argv=0x7ffffc74
at /home/jonathan/
Seems to be correlated with a flaky connection.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #32 |
not sure if this is what you saw as well, Ben.
In Mozilla Bugzilla #565065, Ben-bucksch (ben-bucksch) wrote : | #33 |
Yes, I saw exactly the same as in initial description, including the very same "\372".
description: | updated |
In Mozilla Bugzilla #565065, Vseerror (vseerror) wrote : | #34 |
many major/hang bugs cite gettimeofday - Bug 533464, Bug 361730, Bug 508263. needs a deeper look. dup of bug 508263?
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #35 |
Created attachment 529281
GDB log
David, I've had another hang at shutdown, but not 100% cpu this time. I did a complete GDB session, and inspected every one of the 15 threads running. One is indeed hanging in the IMAP code. The full backtrace is near the end of the file. Relevant parts:
#5 nsPipeInputStre
at /home/jonathan/
No locals.
#6 0x00007fe2a1cebfd5 in nsPipeInputStre
this=
writer=
readCount=
at /home/jonathan/
writeCount = 1924833280
originalLen = <value optimized out>
rv = <value optimized out>
segment = 0x7fe26d9fc858 "\n"
segmentLen = 32738
#7 0x00007fe2a20616b8 in nsMsgCompressIS
aBuf=
at /home/jonathan/
bytesRead = 0
rv = <value optimized out>
rv = <value optimized out>
#8 0x00007fe2a2044619 in nsMsgLineStream
this=
aNumBytesIn
prv=
at /home/jonathan/
i = <value optimized out>
rv = <value optimized out>
endOfLine = <value optimized out>
startOfLine = 0x7fe272baa000 "+ idling\r\n"
#9 0x00007fe2a1fb81b8 in nsImapProtocol:
this=
at /home/jonathan/
rv = 0
kungFuGrip = {<nsCOMPtr_base> = {
mRawPtr = 0x7fe275d70950}, <No data fields>}
newLine = <value optimized out>
#10 0x00007fe2a1fc7b6e in nsImapServerRes
this=
at /home/jonathan/
rv = 1
#11 0x00007fe2a2085569 in nsIMAPGenericPa
this=
at /home/jonathan/
ok = <value optimized out>
#12 0x00007fe2a20855ff in nsIMAPGenericPa
this=
at /home/jonathan/
No locals.
#13 0x00007fe2a1fc93d2 in nsImapServerRes
this=
aIgnoreBadA
at /home/jonathan/
pl...
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #36 |
this stack trace just means that we have an imap thread waiting for data - it doesn't mean anything other than that. Other threads could be blocking the shutdown process - I've seen a strange behavior with the UI thread and PSM where the UI thread is blocked on shutdown trying to clean up a PSM thread.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #37 |
Created attachment 529838
possible fix for one case of hang on shutdown
I just had a hang on shutdown like this happen to me today. Poking around, I discovered that the url was not in the imap log, which meant we had run the url after the shutdown process had turned off logging, and I discovered that mailnews had been shut down. Since we ran the url anyway, I believe this meant that the account manager had been destroyed and then recreated, with m_shuttingDown set to false. I remembered from previous experience that sometimes we reload the accounts at shutdown, which means that every once in a while, some piece of code tries to do stuff after shutdown.
So this fix does a couple things:
1. Make the variables that track whether we're shutting down truly global
2. Move the check for shutting down lower down in the IMAP call stack (but still on the UI thread) so that various edge cases don't avoid the check. One edge case is queued urls, though I know that's not what happened to me or others, because queuing urls shows up in the protocol log.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #38 |
try server builds here - http://
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #39 |
fixed on trunk - http://
I'm going to mark this fixed - the symptom is (usually) one imap thread blocked waiting for input, no other threads blocked, and a hang on shutdown. Protz, I'm not sure if this is what you are seeing, but I would be very interested to hear if you see it with builds going forward. As I mentioned before, the other symptom is that the imap url that's blocked doesn't show up in an imap protocol log because it was started after logging is torn down.
In Mozilla Bugzilla #565065, Jonathan Protzenko (jonathan-protzenko) wrote : | #40 |
Sure. I haven't seen this happen frequently lately, but I'll make sure I try to get a relevant backtrace in case this happens again. Ehsan, you said your Thunderbird reliably had this issue, do you think you could try this out?
In Mozilla Bugzilla #565065, Ehsan-mozilla (ehsan-mozilla) wrote : | #41 |
(In reply to comment #37)
> Sure. I haven't seen this happen frequently lately, but I'll make sure I try to
> get a relevant backtrace in case this happens again. Ehsan, you said your
> Thunderbird reliably had this issue, do you think you could try this out?
Sure. Do I need to download a trunk build for this? (From where?! :D)
Will that build blow away my profile? Specifically, should I make a backup before running it?
In Mozilla Bugzilla #565065, Ehsan-mozilla (ehsan-mozilla) wrote : | #42 |
I mean, I can probably run the trunk build regularly if I can get some of my extensions working on it.
In Mozilla Bugzilla #565065, Dbienvenu (dbienvenu) wrote : | #43 |
Ehsan, tomorrow's miramar nightly builds will have this fix in it - http://
You can disable extension compatibility checking and most extensions will run. Binary extensions like Lightning or Enigmail aren't so lucky.
However, I thought your big issue was a hang after wakeup from sleep, not a hang on shutdown. This patch has no effect on the former, but there's work going on in Bug 508263 that may help with that. (Sorry, all these bugs are dirty, in that they conflate a bunch of issues)
In Mozilla Bugzilla #565065, Sgautherie-bz (sgautherie-bz) wrote : | #44 |
Helgi Örn Helgason (sacredeagle) wrote : | #1 |
Same here:
3.1.10+
Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux
Micah Gersten (micahg) wrote : | #2 |
Thank you for reporting this. This bug has actually been fixed upstream in Thunderbird 3.3. Please report any other issues you may find.
Changed in thunderbird (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in thunderbird: | |
importance: | Unknown → Critical |
status: | Unknown → Fix Released |
mejo (jonas-freesources) wrote : | #45 |
This bug may have been fixed in thunderbird 3.3, but this version is not available in Natty yet. And I'm still discovering this bug. Thus I suggest to change the status back to 'Confirmed'.
In Mozilla Bugzilla #565065, Philip Prindeville (3-philipp) wrote : | #46 |
Was this released in 5.0? Because I'm still seeing a hang on quit... now with Lion.
In Mozilla Bugzilla #565065, Standard8 (mbanner) wrote : | #47 |
(In reply to comment #42)
> Was this released in 5.0? Because I'm still seeing a hang on quit... now
> with Lion.
Yes it was, but please file a new bug, especially as you've changed OS. It could be that you're seeing something different.
In Mozilla Bugzilla #565065, Vseerror (vseerror) wrote : | #48 |
the hints that the patch is in v5 are comment 40 which cites Miramar, and Target Milestone=
If you still see a hang, please consult https:/
mejo (jonas-freesources) wrote : | #49 |
please, can you push either thunderbird 5, or a version with backported fix for this issue to Natty? This bug is annoying. I often don't realize the thunderbird crash immediately, and wonder why cpu heat and cpu fan both run crazy, and the battery lifetime decreases that fast.
Sometimes I even left the laptop in that state for some time while doing something else, and was shocked that it was hot like burning when I came back. This is the main reason why I consider the bug as critical.
Chris Coulson (chrisccoulson) wrote : | #50 |
If you want a more up-to-date version of Thunderbird on Ubuntu, I highly recommend using the thunderbird-stable PPA:
https:/
Michael Nagel (nailor) wrote : | #51 |
Is this still an issue with thunderbird 12 installed by default now?
Changed in thunderbird (Ubuntu): | |
status: | Triaged → Incomplete |
mejo (jonas-freesources) wrote : | #52 |
at least for me, the bug disappeared with the upgrade to ubuntu 12.04 and thunderbird 12.
Changed in thunderbird (Ubuntu): | |
status: | Incomplete → Fix Released |
I haven't found a reliable way to trigger this. Basically, when I shutdown Thunderbird, it goes 100%cpu and doesn't respond anymore, and I have to kill it.
The last time this happened, I managed to strace the running process. Here's what I got:
Process 4156 attached - interrupt to quit POLLIN| POLLPRI} , {fd=11, events= POLLIN| POLLPRI} , {fd=12, events= POLLIN| POLLPRI} , {fd=13, events= POLLIN| POLLPRI} , {fd=17, events=POLLIN}, {fd=44, events=POLLIN}, {fd=47, events=POLLIN}, {fd=10, events=POLLIN}, {fd=18, events=POLLIN}], 11, 0) = 1 ([{fd=18, revents=POLLIN}]) {1273581961, 969398}, NULL) = 0 POLLIN| POLLPRI} , {fd=11, events= POLLIN| POLLPRI} , {fd=12, events= POLLIN| POLLPRI} , {fd=13, events= POLLIN| POLLPRI} , {fd=17, events=POLLIN}, {fd=44, events=POLLIN}, {fd=47, events=POLLIN}, {fd=10, events=POLLIN}, {fd=18, events=POLLIN}], 11, 0) = 0 (Timeout) {1273581961, 972734}, NULL) = 0 POLLIN| POLLPRI} , {fd=11, events= POLLIN| POLLPRI} , {fd=12, events= POLLIN| POLLPRI} , {fd=13, events= POLLIN| POLLPRI} , {fd=17, events=POLLIN}, {fd=44, events=POLLIN}, {fd=47, events=POLLIN}, {fd=10, events=POLLIN}, {fd=18, events=POLLIN}], 11, 0) = 0 (Timeout)
read(3, 0xb625a058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=
read(18, "\372", 1) = 1
gettimeofday(
read(3, 0xb625a058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=
gettimeofday(
read(3, 0xb625a058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=
I filled 5mb of logs with the same sequence repeated over and over again, until I got bored and killed Thunderbird.
There's a few reports of similar issues but I'm confused by the insane number of calls to gettimeofday, and I don't think I can reliably consider this as a duplicate of other report issues involving 100% cpu at shutdown, so I'm reporting here in case we're missing something important.
I'm using the official b2 build FWIW.