Closed Bug 535822 Opened 15 years ago Closed 13 years ago

100% CPU use after exit and open imap connections (IMAP IDLE command is used) - shutdown hangs

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Version:
1.9.1 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: maksverver, Unassigned)

Details

(Keywords: hang, Whiteboard: [has stacktrace])

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091108 Gentoo Firefox/3.5.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091210 Thunderbird/3.0 I'm using Thunderbird with an IMAP account and two Usenet accounts. None of these use TLS or anything fancy. After closing the Thunderbird window, the GUI disappears, but a background process remains that uses 100% CPU permanently and never seems to exit (even though the CPU usage is much lower during normal use, at least on average). After this occurs, I cannot restart Thunderbird (since it's still running) and I have to kill the thunderbird-bin process manually. This seems to occur more often if Thunderbird has been running for a long time, but I haven't investigated this in detail. Reproducible: Sometimes Steps to Reproduce: Start Thunderbird, work with it for a while, close the window. Actual Results: There is a thunderbird-bin that permanently uses 100% CPU for no reason. I've let it run for over 5 hours and it doesn't exit, so as far as I can tell it never will. Expected Results: Immediately, or at least soon, after closing the Thunderbird window, the thunderbird-bin process should exit. I'm using XFCE on Gentoo (AMD64) with X.org 1.7.3.901.
Severity: critical → major
* run netstat - how many connections are shown to ldap, imap mailserver, etc. * if you are running lightning extension, does the shutdown hang happen without lightning? * obtain hang gdb stack and attach file to bug other hang bugs https://bugzilla.mozilla.org/buglist.cgi?keywords=hang;keywords_type=allwords;short_desc=cpu;field0-0-0=short_desc;resolution=---;query_format=advanced;short_desc_type=allwordssubstr;type0-0-0=nowordssubstr;value0-0-0=attach%20mov%20delet;product=MailNews%20Core;product=Thunderbird
Severity: major → critical
Version: unspecified → 3.0
This is the (filtered/edited) output from netstat: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 37 0 <local>:3987 <remote1>:imap CLOSE_WAIT tcp 0 0 <local>:43986 <remote1>:imap CLOSE_WAIT tcp 0 0 <local>:43982 <remote1>:imap ESTABLISHED tcp 0 0 <local>:43984 <remote1>:imap CLOSE_WAIT tcp 66 0 <local>:55417 <remote2>:nntp CLOSE_WAIT After waiting ten minutes or so, the NTTP connection was gone, but the IMAP connection remained for at least 20 minutes after exiting. (Note that I had two Usenet servers configured, so one was already gone when I ran netstat. Maybe the NTTP connections time out while the IMAP connections linger.) I'm not using lightning (at least I never heard of it before, so I don't think I am). The gdb backtrace seems to change a little whenever I interrupt the process. Here's one backtrace: #0 0x00007f9e66763099 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #1 0x00007f9e667634f1 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f9e66763a20 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f9e5cbe18bb in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #4 0x00007f9e5cbe19c7 in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #5 0x00007f9e6770f9b3 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #6 0x00007f9e676e58f2 in NS_ProcessNextEvent_P(nsIThread*, int) () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #7 0x00007f9e6770fccf in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #8 0x00007f9e6771083f in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #9 0x00007f9e676e8411 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #10 0x00007f9e679715f8 in ?? () from /usr/lib64/mozilla-thunderbird/libxul.so #11 0x00007f9e67974de7 in XRE_main () from /usr/lib64/mozilla-thunderbird/libxul.so #12 0x0000000000401a0b in ?? () #13 0x00007f9e6736bbbd in __libc_start_main () from /lib/libc.so.6 #14 0x00000000004017f9 in ?? () #15 0x00007fff854ae468 in ?? () #16 0x000000000000001c in ?? () #17 0x0000000000000001 in ?? () #18 0x00007fff854affe9 in ?? () #19 0x0000000000000000 in ?? () Here's another one: #0 0x00007f9e67b9612d in read () from /lib/libpthread.so.0 #1 0x00007f9e5cbcf014 in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #2 0x00007f9e6675ffeb in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #3 0x00007f9e667638f0 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0x00007f9e66763a20 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #5 0x00007f9e5cbe18bb in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #6 0x00007f9e5cbe19c7 in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #7 0x00007f9e6770f9b3 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #8 0x00007f9e676e58f2 in NS_ProcessNextEvent_P(nsIThread*, int) () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #9 0x00007f9e6770fccf in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #10 0x00007f9e6771083f in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #11 0x00007f9e676e8411 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #12 0x00007f9e679715f8 in ?? () from /usr/lib64/mozilla-thunderbird/libxul.so #13 0x00007f9e67974de7 in XRE_main () from /usr/lib64/mozilla-thunderbird/libxul.so #14 0x0000000000401a0b in ?? () #15 0x00007f9e6736bbbd in __libc_start_main () from /lib/libc.so.6 #16 0x00000000004017f9 in ?? () #17 0x00007fff854ae468 in ?? () #18 0x000000000000001c in ?? () #19 0x0000000000000001 in ?? () #20 0x00007fff854affe9 in ?? () #21 0x0000000000000000 in ?? () And a third one: #0 0x00007f9e67b9612d in read () from /lib/libpthread.so.0 #1 0x00007f9e64b87450 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f9e64b87948 in xcb_poll_for_event () from /usr/lib/libxcb.so.1 #3 0x00007f9e6643a305 in ?? () from /usr/lib/libX11.so.6 #4 0x00007f9e6643ab87 in _XEventsQueued () from /usr/lib/libX11.so.6 #5 0x00007f9e66423add in XPending () from /usr/lib/libX11.so.6 #6 0x00007f9e65ba4a56 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #7 0x00007f9e66763131 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #8 0x00007f9e667634f1 in ?? () from /usr/lib/libglib-2.0.so.0 #9 0x00007f9e66763a20 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #10 0x00007f9e5cbe18bb in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #11 0x00007f9e5cbe1a19 in ?? () from /usr/lib/mozilla-thunderbird/components/libwidget_gtk2.so #12 0x00007f9e6770f9b3 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #13 0x00007f9e676e58f2 in NS_ProcessNextEvent_P(nsIThread*, int) () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #14 0x00007f9e6770fccf in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #15 0x00007f9e6771083f in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #16 0x00007f9e676e8411 in ?? () from /usr/lib64/mozilla-thunderbird/libxpcom_core.so #17 0x00007f9e679715f8 in ?? () from /usr/lib64/mozilla-thunderbird/libxul.so #18 0x00007f9e67974de7 in XRE_main () from /usr/lib64/mozilla-thunderbird/libxul.so #19 0x0000000000401a0b in ?? () #20 0x00007f9e6736bbbd in __libc_start_main () from /lib/libc.so.6 #21 0x00000000004017f9 in ?? () #22 0x00007fff854ae468 in ?? () #23 0x000000000000001c in ?? () #24 0x0000000000000001 in ?? () #25 0x00007fff854affe9 in ?? () #26 0x0000000000000000 in ?? () Let me know if there is anyhting else I should do. (For example, I might be able to get more meaningful data from gdb if I re-emerge Thunderbird with debug symbols.)
(In reply to comment #2) > Let me know if there is anyhting else I should do. (For example, I might be > able to get more meaningful data from gdb if I re-emerge Thunderbird with debug > symbols.) That would be nice ! One other thing would be to run Thunderbird in -safe mode and see if your is still present (http://kb.mozillazine.org/Safe_mode) ? Where did you get thunderbird (from a gentoo repo , or from ftp.mozilla.org) ?
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Summary: 100% CPU use after exit → 100% CPU use after exit and open imap connections
Whiteboard: [has stacktrace]
Version: 3.0 → 1.9.1 Branch
Running(In reply to comment #3) > One other thing would be to run Thunderbird in -safe mode > and see if your is still present? Unfortunately, with -safe the problem persists. (I'm not too surprised, because I don't think I customized much, except for adding accounts.)
> tcp 0 0 <local>:43982 <remote1>:imap ESTABLISHED "100% CPU(inifinite loop, retry roop, ...) upon termination of Tb" is reported to some bugs. I suspect issue around multi-threading on multi-cpu. I also suspect issue around IDLE, especially when contension occurred between notification via. IDLE by server and Tb's access by "check new message for ever NNN minutes" and/or session termination request by Tb upon shutdown, because such problem of Tb is mainly reported by IMAP users, and because session with IMAP server is still ESTABLISHED in your case. Can you afford to "no IDLE command use" in daily use of your Tb? (new mail to Inbox or some other IMAP folders is not detected automatically, unnless "check for new message every NNN minutes" is used or the IMAP folder is clicked manually.) If yes, disable IDLE command use(Server Settings/Advanced). Will frequency of problem be reduced by it?
> I suspect issue around multi-threading on multi-cpu. I'm using a single single-core CPU, so this might be a different problem. > I also suspect issue around IDLE I think you're right: disabling IDLE support seems to fix the problem. Not a true solution of course (good IDLE support would be nice to have) but a viable workaround.
Adding IDLE to bug summary for ease of search.
Summary: 100% CPU use after exit and open imap connections → 100% CPU use after exit and open imap connections (IMAP IDLE command is used)
Keywords: hang
(In reply to comment #6) > > I also suspect issue around IDLE > > I think you're right: disabling IDLE support seems to fix the problem. Not a > true solution of course (good IDLE support would be nice to have) but a viable > workaround. Can you tell us a bit more about your server's configuration (type config options) ? Or better would it be possible to have a test account so we can try to reproduce ourselves and try to fix the issue ?
> Can you tell us a bit more about your server's configuration? The server is running Dovecot on Arch Linux. As far as I know, it doesn't have any weird configuration options. If I send a CAPABILITY command the response is: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH AUTH=PLAIN AUTH=LOGIN > Or better would it be possible to have a test account so we can try > to reproduce ourselves and try to fix the issue ? This server is only accessible through a VPN and I'd prefer not let outsiders in, sorry. If this means you can't debug this issue, I definitely won't blame you (on the contrary, I'd like to thank the people involved for their replies so far!)
Summary: 100% CPU use after exit and open imap connections (IMAP IDLE command is used) → 100% CPU use after exit and open imap connections (IMAP IDLE command is used) - shutdown hangs
This *seems* to also happen on Mac OS X 10.6 (Snow Leopard) and probably earlier.
bienvenu, wada, wasn't something with idle fixed in the last couple months? xref bug 468490
After Wayne's comment I've re-enabled the IDLE command and so far I've not seen the problem anymore. So although I don't know whether or not the underlying bug was fixed, the problem went away for me.
I've seen this once very recently.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've seen something like this recently. I don't know how to reproduce it but I think I can predict if it's going to happen when I exit. Sometimes the mouse activity indicator (hourglass or spinning circle) is active but never finishes. Exiting then usually leaves a leftover process with high CPU usage which doesn't finish. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1
I've seen this bug's phenomenon first time during test for Bug 572974. (1) Tb 3.2pre of MS Win-SP SP3. IDLE is enabled. Periodical mail check is not activated. offline-use=off to prohibit auto-sync. mail.server.default.mime_parts_on_demand=false to force whole maail download Open several folders to use several cached connections. (2) Repeat click of 2 mails(multipart/mixed, 12MB and 20MB) in an IMAP folder. Due to Bug 565852, logout/login happens upon each mail click. (3) Pull off LAN cable while executing step (2) (4) Plug in LAN cabble (5) Repeat step (2) to step (4) While repeating (2) to (4), something wrong happened(folder open doesn't look completed, thread pane is blank when rebuild-index, ...). So I terminated Tb in order to restart Tb => Tb didn't terminate, CPU 100%. Checked file I/O by Tb using Process Monitor => no file I/O was observed. As no new mail is arrived, activity at cached connection is following only in my test. - a session for IMAP folder of (2) logout, login, and fetch body[1], is executed repeatedly - other sessions IDLE each 29 sec
Matt, Maks, do you still see this problem? And if you do not see it, do you recall in what version it went away? bug 572974 fixed in tb 3.1.3 Bug 565852 fixed in tb 3.1.8/3.1.9
I don't think my issue was fixed yet, but it doesn't seem to hit me very often either. Also, for me this is mainly a windows issue and the original bug is from linux. I think I have noticed it recently in both windows 7 and on windows xp. However on windows xp, we were using a really crufty profile recently upgraded from tb 2. Since creating a new profile, it hasn't been a problem that I can tell yet.
I have re-enabled use of the IDLE command. It's too early to tell if the problem is gone (because it was never very predictable/reproducible) but I'll let you know if it pops up again.
Yes this bug is still alive. I just got hit by it today. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
Maks writes "I haven't seen it in a while now. I'm not sure if I have had IDLE support on continuously since I last posted to the bug tracker, but I'm pretty sure it has been on since upgrading to version "5.0", and I haven't had the problem yet. .. probably fixed as far as I'm concerned, though it's hard to say for sure because the root cause was never identified." so => WFM Matt, If you still see this with newest versions, please consult https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring&keywords=hang&keywords_type=allwords&list_id=875345&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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.