User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050209 Firefox/1.0+ Build Identifier: version 7.0 (20050212) CVS Trunk builds for about the last 5 days. When exiting TB, it appears to shutdown but still appears in Task Manager but using 0% CPU and the memory usage doesn't change which suggests that it has hung late in the shutdown process. Although it is possible to kill this zombie process in Task Manager the big problem is that it results in a corrupt profile. Mail and News still work any customizations, e.g. column order in the thread pane, the toolbar layout, etc. are lost. I have tried deleting the following files (all of which have solved issues with new trunk builds in the past): compreg.dat panacea.dat localstore.dat mailViews.dat xpti.dat XUL.mfl but none have fixed this problem. No errors/warnings/messages are seen when starting TB from the command line but I do get this Error in the JS Console at startup which I wasn't seeing before: Error: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: file:///C:/Program%20Files/MozillaThunderbird/components/nsDefaultCLH.js :: clh_handle :: line 81" data: no] Source File: file:///C:/Program%20Files/MozillaThunderbird/components/nsDefaultCLH.js Line: 81 Creating a new profile works for a while, but eventually (after only a few exit/restarts) the problem reappears. I've zapped my src tree, and MOZ_OBJDIR, re-pulled the tree but it makes no difference. I can't think of anything else to try and it's getting a real PITA. Anyone shed any light? Reproducible: Sometimes
everyone gets that js exception. I don't think it's an issue. Are you using IMAP?
Yes. Both mail accounts are IMAP (my own server)
Summary: Thunderbird fails to exit properly and loses customixations → Thunderbird fails to exit properly and loses customizations
Version: unspecified → Trunk
Created attachment 174302 [details] [diff] [review] proposed fix This fixes some cases of deadlock between the ui thread and the imap thread. Shutdown happens on the ui thread. If a connection is running a url, we have to be careful about killing it. If a url is running, we can't wait for a response from the close or logout commands. And if a url is writing lots of data to the server, like appending messages to a folder, we can't even send a close/logout because it would block and deadlock... this should fix most of the deadlock cases. I don't know why you're losing configuration settings, but this should help with the deadlock.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → ASSIGNED
Attachment #174302 - Flags: superreview?(mscott)
Component: General → Networking: IMAP
Product: Thunderbird → Core
Comment on attachment 174302 [details] [diff] [review] proposed fix a=sspitzer, assuming you get sr from mscott.
Attachment #174302 - Flags: approval1.8b+
Attachment #174302 - Flags: superreview?(mscott) → superreview+
can you try a trunk build from tomorrow? I've checked in this fix, which should help.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
I applied the patch and spun a new build but the problem persisted. I've just zapped MOZ_OBJDIR and am currently doing a full rebuild - I'll let you know how it goes.
oh, if you've got a debug build, could you break into the debugger and see where we're hanging?
The complete rebuild seems to have done the trick. I created a new profile and started/stopped TB 30 times, gradually adding a new mail or newsgroup and copying across my user.js, userChrome.css etc. and it's worked fine. The old profile was still horked until I deleted panacea.dat, localstore.dat, XUL.mfl and mailViews.dat when it started working again even after ~20 restarts. Your patch was the only thing I added to my tree, i.e. I didn't pull a new tree. Thanks for the quick solution David.
if you only rebuilt the imap directory, and not the imap directory + mailnews/build, then my fix wouldn't have helped. Or did you do a depend build from the top (that should have helped...) well, anyway, glad it's working for you.
I just ran make -f client.mk build_all from the top but, as I've seen before, this doesn't always work when you've just patched one or two files.
You need to log in before you can comment on or make changes to this bug.