Closed Bug 246909 Opened 20 years ago Closed 18 years ago

Thunderbird process remain active after closing

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hetz, Assigned: Bienvenu)

References

Details

Attachments

(11 files)

prefs.js from my TB profile
6.15 KB, application/octet-stream
Details
prefs.js from my TB profile
6.15 KB, text/plain
Details
NNTP log
3.79 KB, text/plain
Details
prefs.js from vseerror
73.82 KB, text/plain
Details
last 150 lines of log
12.18 KB, text/plain
Details
log up to and including shutdown
107.90 KB, text/plain
Details
entries from shutdown to killing of the TB process
5.53 KB, text/plain
Details
log of test 2 UP TO shutdown
9.85 KB, text/plain
Details
log of test 2 AFTER shutdown and kill process
9.79 KB, text/plain
Details
prefs.js for non-existing tbird process
21.60 KB, text/plain
Details
fix for the imap empty trash/cleanup inbox on exit case
1.10 KB, patch
mscott
: superreview+
asa
: approval-aviary1.1a1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Build Identifier: 

It seems like Thunderbird on Windows doesn't really closes when clicking on the 
X to close it.
Most of the time its closes correctly and the gui is always getting closed, but 
the problem happends specially when the mail tries to receive data in the 
background.
Until you kill the process manually, you cannot re-launch Thunderbird.

Reproducible: Always
Steps to Reproduce:
1. Open Thunderbird, let it get mail
2. Close it
3. If TB tries to download mail in the background and you'll close it, you'll 
find that the GUI is being closed, but the process is left open (see Task 
Manager)

Actual Results:  
Process left until being killed manually.

Expected Results:  
Close everything ;)
I am experiencing a similar problem.  Sometimes (~30%), Thunderbird remains
running if I choose "exit" from the "File" menu.  All windows close and the
application seems to go away.  It remains in the Task Manager.  If I try to
launch Thunderbird nothing appears to happen (I might be asked to select a
profile).  Multiple thunderbird.exe's appear in the Task Manager.  Sometimes
killing 1 kills them all.  Sometimes I have to kill each individually.  It
probably depends on which I pick to kill.

I experience this with released versions 0.6, 0.7, 0.73, and 0.8.  I run 0.5
with no problems.

It feels like this issue may be related to IE.  I sometimes find IE hanging
at the same time, although I usually do not observe this correlation.
I have now experienced this problem with 0.5.

It coincided with my having an Internet Explorer window open that was wedged.

The Thunderbird process would not die.

When I killed Internet Explorer, Thunderbird died.

I don't know why this occurs more frequently with 0.6, 0.7, 0.73, and 0.8.  I 
don't know if it was something about Thunderbird that caused IE to get 
wedged.  Killing Thunderbird did not unblock (or kill) the IE process.
My report regarding similar behavior on 0.5 may be misleading.

With 0.6, 0.7, 0.73, and 0.8, I experience this problem several to many times 
a day, making Thunderbird almost unusable.

With 0.5, the problem has come up only once in the last month.  This might 
have been a different problem.

I see that this Bug is still marked Unconfirmed.  I am willing to provide more 
information to get it addressed.
I have upgraded to 0.9.

Occurrences of this bug seem to be somewhat diminished.  It does seem to crop 
up about once or twice a day, still.
Hetz Ben Hamo and Gil Neiger, do you use "Run Filter on folder"?
I am running 1.0 (released dec-07-2004), and see this every time. I can
reproduce it just by opening TB and closing it again. I am not using 'run filter
on folder'... in fact, I can't, as the only account I have set up is a newsgroup
account that does not support this feature. :(

Everybody seems to be cross-posting comments to bug 251759; should these be
marked as duplicates?
Matthew, can you send me your prefs.js so I can see what your setup is? Do you
have cleanup inbox on exit, or empty trash on exit set for any of your accounts?
(In reply to comment #6)
> in fact, I can't, as the only account I have set up is a newsgroup account
> that does not support this feature. :(
Interesting.
Matthew, send your prefs.js to David as soon as possible, please.
(In reply to comment #7)
> Matthew, can you send me your prefs.js so I can see what your setup is? Do
you
> have cleanup inbox on exit, or empty trash on exit set for any of your
accounts?

Empty trash is not set... and I have no accounts with 'cleanup inbox' as an
option; just one NNTP account.
(In reply to comment #7)
> Matthew, can you send me your prefs.js so I can see what your setup is? Do
you
> have cleanup inbox on exit, or empty trash on exit set for any of your
accounts?

Empty trash is not set... and I have no accounts with 'cleanup inbox' as an
option; just one NNTP account.
Attachment #168340 - Attachment mime type: application/octet-stream → text/plain
apologies for the double post
This is a real bug. I have had this problem on more than one machine (office and
home) on versions dating back to 0.6 including 1.0. I only seem to have this
problem on machines with XP. It happens about 1/3 of the time that when I exit
Thunderbird, the process remains running. The critical part of this for me is
that mail continues to download to the machine even though I thought I ended the
application!. I can upload my prefs.js if you wish to see it.  -- Paul Freet
does everyone this is happening to just have a single news account? I'll try
setting up a profile like that.
(In reply to comment #9)
Matthew, since you define News server only(no POP3, no IMAP, no SMTP), 
it is impossible to imagine other than something wrong in News server access.
Can you get protocol log and attach log to this bug? (do not paste log data)
See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#nntp
Please do not forget to change set NSPR_LOG_MODULES=protocol:5 to NNTP:5
Please note that log file is overlayed on restart.

(1) Activate protocol log and start Thunderbird
(2) Usual news server access
(3) Close Thunderbird => Probably process is still active after window close
(4) Watch thunderbird process activity using "Task Manager"
    if you use MS Win-NT family(Win-2K,Win-XP)
(5) Wait for a while (more than 5 minutes).
(6) Kill Thunderbird process and save protocol log file
Attached file NNTP log — 
Well, wtf, it's suddenly behaving itself. Pretty sure I didn't change
anything...
Attaching log file anyway.
(In reply to comment #15)
>Well, wtf, it's suddenly behaving itself. Pretty sure I didn't change anything...
Matthew, did you re-boot MS Win or logoff/re-login MS Win user after you
experienced this bug's problem?
If yes, did this bug's problem occur after the first re-boot or re-login
following the problem?
(In reply to comment #16)
> ...did you re-boot MS Win or logoff/re-login MS Win user after you
> experienced this bug's problem?

My computer was turned off yesterday, so right now I'm fresh-booted. I don't
recall if I previously experienced the bug after a reboot, or if I only saw it
immidiately after installing.

I tend to reboot rarely, including after installs, and have very seldom
experienced any problems because of this... maybe FF was an exception. Sorry if
I'm wasting everyone's time. I'll pop back in if I start seeing problems again.

Hetz Ben Hamo(reporter), Gil Neiger and Paul Freet,
are you still experiencing the problem?
If yes, does problem occur even on newest Thunderbird 1.0?
(In reply to comment #18)
> Hetz Ben Hamo(reporter), Gil Neiger and Paul Freet,
> are you still experiencing the problem?
> If yes, does problem occur even on newest Thunderbird 1.0?

Because of the holidays, I have not been using Thunderbird extensively since I 
upgraded to 1.0 a week or so ago.

I can report that I continue to see a related problem:
1.  Start Thunderbird
2.  Choose profile
3.  No window appears; process remains in Task Manager.
4.  Kill process in Task Manager.
5.  Repeat steps 1-4 some number of times.
6.  Eventually, Thunderbird windows appear after step 2.
I can now report that I consistently experience this bug with 1.0.  It affects 
me several times a day.  It is not so bad that I feel a need to drop back to 
0.5, but it is almost bad enough for that.

I use two different profiles, and I notice this bug most often when switching 
between them (i.e., quitting thunderbird from one profile and immediately 
starting it up again with another).  Maybe exploration of the root cause 
should focus on situations with multiple profiles.

(Actually, it's not clear to me that anyone is investigating ways to fix this 
bug.  Does anyone else know otherwise?)
(In reply to comment #20)
> (i.e., quitting thunderbird from one profile and immediately 
> starting it up again with another).

Apllication window closing usually does not mean complete process termination.
Since Thunderbird has timer-pop process for accesing to mail/news servers, these
hidden processes should be terminated.
Gil Neiger, does Thunderbird never terminate (profile is used forever) in your
environment?
Do you mean "Quitting, wait for a while, then restart" can not be a work around?
If no, I think your comment #20 case is not this bug, rather new request of
"Don't close window until all hidden processes are terminated."
Unfortunately, I continue to see this problem. When this problem manifaests
itself, the application process continues to run indefinately (hours). BTW, I
have multiple email accounts some of which are only for outgoing mail, but no
news accounts. I also have Outlook open which I use for Contacts not email. Hpoe
you have some ideas soon. Maybe I need a clean install with a new profile??
(In reply to comment #21)
> Does Thunderbird never terminate (profile is used forever) in your
> environment?
> Do you mean "Quitting, wait for a while, then restart" can not be a work 
around?
> If no, I think your comment #20 case is not this bug, rather new request of
> "Don't close window until all hidden processes are terminated."

After running very carefully for the last 10 days (e.g., always invoking Task 
Manager before Thunderbird), I have to say that the "wait for a while" 
approach seems to work and, therefore, a fix of "Don't close window until all 
hidden processes are terminated" may be adequate.

I believe that I have seen, in the past, longer-lived processes that will not 
die, even after a while.  It seems to me that, if I restart Thunderbird before 
old processes die, then the processes will not die on their own.  It may be 
this behavior that I was seeing in past cases.


I don't understand #23. Maybe I'm talking about a different problem. This
workaround certianly won't work for me. I'll try to describe the problem I'm
seeing again. FYI, this is happening on multiple computers. Sometimes (1 out of
5 or possibly more often) when I run Thunderbird for a bit and close the
application, the process does not stop. Ever! There's no time-out issue here, it
keeps running, for days if I let it. The only way to stop Thunderbird is to find
and kill the process using task manager in Windows. Thunderbird happily
continues to download POP mail for hours and hours even after I have closed the
application. I am sitting here at my office unable to get my email, because my
computer at home is grabbing all my POP mail - even though I exited the
application 12 hours ago. How can this be anything other than a Critical BUG?! 

I have about ten email accounts created in Thunderbird, some of which are for
outgoing mail only. I wonder if the problem is related to the outgoing-only
email accounts. They cannot retreive mail - I only use them to send mail. I have
unchecked the box in  server setitngs for the acocunt to get mail - you have to
sort of trick Thunderbird to have outgoing-only mail accounts. Maybe to recreate
the problem you could create one or more dummy email accounts. Ones that cannot
log into a POP server. And then try to exit the application and see if it
properly exits. I have found other mentions of this exact problem doing Google
searches so it isn;t just me.

  - Paul 
(In reply to comment #24)
>Maybe I'm talking about a different problem.
Yes. You are confusing.
This bug's problem(also your problem and comment #19 problem of Gil Neiger) is
"never ending process", but problem discussed in comment #20, comment #21 and
comment #23 is "longer termination time than Gil Neiger expects".

I suspects "forever wait in network access" due to error(a kind of hang) on
other than Thunderbird(MS Win or other application), although I also suspect a
kind of flaw of Thunderbird(eg. lack of timeout detection.)
This is because the bug reporter doesn't experience problem after re-boot, and
Gil Neiger says "When I killed Internet Explorer, Thunderbird died." in Bug
251759 Comment #5, which is a bug for similar problem(I think DUP of this bug).

Bug 278144 is a one of my suspects (see Bug 278144 comment #7.) 
*** Bug 251759 has been marked as a duplicate of this bug. ***
Changing summary(add "process") for ease of search.
Summary: Thunderbird is not closing → Thunderbird process remain active after closing
Why is this bug still UNCONFIRMED? Yesterday, I closed Thunderbird. The process
continued to run for 24 hours until I killed it this morning. How is this not a
bug? How many thousands of other people are experiencing this problem and
solving it by going back to Outlook? Why is this getting no attention?
I'll confirm it, though I've not been able to reproduce it. I've been adding
timeout detection to mailnews, now that our networking code has timeout
detection. So in trunk builds starting tomorrow, all our protocols should have
timeout detection. I'm not convinced that this will help, but it might be worth
trying downloading tomorrow's trunk build and see if this is fixed...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file prefs.js from vseerror — 
Seeing this on nightly version 1.0+ (20050504). Started happening around May 1.


Not sure if I can recreate at will.  However, I have seen it twice in the last
several days.
This is very difficult to reproduce - I still suspect this has to do with
network activity happening at just the wrong time during shutdown. I wonder if
this is simlar to a problem I saw in the imap code, where some code is blocked
on a monitor which gets notified by one thread, but destroyed by another thread
before the blocked code can wake up.

Generating a protocol log of all the protocols that might be active at shutdown
(pop3, nntp, imap) might be helpful. We could look at the end of the log and see
if we're getting new mail at shutdown.

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

to generate a protocol log for multiple protocols, you can do something like this:

set NSPR_LOG_MODULES=POP3:5,NNTP:5,IMAP:5

i.e., list each possible protocol, separated by commas.
Attached file last 150 lines of log — 
from when TB process was still running after shut down.
log file in comment 33 is the tail of a 1meg log file, but this is a
significantly reduced test case.  

In this case I did nothing more in the span of a minute than startup TB, login,
select e message, edit as new, got the message "An error occured while creating
message window" as described in Bug 203555 and attempt to shut down TB.

This first log file ends at shutdown.  The next file will be from AFTER the
point of shutdown where the TB process is hung, but apparently(?) still
generating log entiries until I killed the process

But still can't get this to a 100% reproduceable list of steps.
We received a BYE this during IDLE - I don't know if this was a result of doing
a shutdown, or something that made the server unhappy.

* BYE Lost mailbox lock

we exit the main loop for that connection, so I believe we're handling the
receiving of the bye correctly, but it is odd. However, the previous 150 log
file just shows us not exiting the IDLE state at all...so we're not even
attempting to clean up that connection. I don't know why that would be.
second test case (but not a short TB session, TB was up several hours)
I'm seeing this too, using 2005-05-10 trunk. About 70-80% of the time, the
process stays around after closing the Thunderbird window. The rest of the time,
it exits cleanly. Let me know if there's anything I can provide that would help.

Error message and the hung process went away after I installed version 1.0+
(20050506) trunk. (problem started with 20050504) No reboot and no other changes
other than restarting TB, obviously. 
(In reply to comment #39)
> I'm seeing this too, using 2005-05-10 trunk. About 70-80% of the time, the
> process stays around after closing the Thunderbird window. The rest of the time,
> it exits cleanly. Let me know if there's anything I can provide that would help.

I am unable to recreate with zip version of 2005-05-10 trunk


an imap protocol log (see
https://bugzilla.mozilla.org/show_bug.cgi?id=246909#c32) and your prefs.js might
be helpful.
Thanks for the suggestion. I can't reproduce the problem with a fresh profile,
and my primary profile is quite old and crusty, so it's probably to blame. (I'll
attach it anyway.)

The IMAP log after the window is closed ends with:
6020[21566d0]: 214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:SendData: 15
expunge6020[21566d0]: ReadNextLine [stream=1bfb0e0 nb=13 needmore=0]
6020[21566d0]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:CreateNewLineFromSocket: * 1
EXPUNGE6020[21566d0]: ReadNextLine [stream=1bfb0e0 nb=12 needmore=0]
6020[21566d0]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:CreateNewLineFromSocket: * 0
EXISTS6020[21566d0]: ReadNextLine [stream=1bfb0e0 nb=26 needmore=0]
6020[21566d0]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:CreateNewLineFromSocket: 15 OK
EXPUNGE completed.6020[21566d0]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:SendData: 16 IDLE0[274620]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:SendData: DONE6020[21566d0]:
ReadNextLine [stream=1bfb0e0 nb=41 needmore=0]
6020[21566d0]:
214d6f0:tayexc13.americas.cpqcorp.net:S-INBOX:CreateNewLineFromSocket: + IDLE
accepted, awaiting DONE command.

This morning it's only reproducing about 40% of the time, but when it hangs,
it's at the same point in the IMAP logfile:

1840[1e0bc98]:
20ca008:tayexc13.americas.cpqcorp.net:S-INBOX:CreateNewLineFromSocket: + IDLE
accepted, awaiting DONE command.
I think the reason the imap log looks that way is that we never clean up the
cached connections, i.e., the shutdown process fails before then. And you have
cleanup inbox on exit selected, but I don't see us issuing the expunge on the
inbox either. In your new profile, did you select cleanup inbox on exit?
(In reply to comment #45)
> I think the reason the imap log looks that way is that we never clean up the
> cached connections, i.e., the shutdown process fails before then. And you have
> cleanup inbox on exit selected, but I don't see us issuing the expunge on the
> inbox either. In your new profile, did you select cleanup inbox on exit?

Deselecting "cleanup inbox on exit" in my primary profile does work around the
problem; it's exited cleanly five times in a row now. 

I didn't point the alternate profile at my IMAP server; I don't want to
accidentally scatter my real mail around. I just used POP to a spare account,
fetched some mail, and exited. I'll try to set up a better test using a clean
account and IMAP, but it won't be until sometime next week.

(In reply to comment #46)
> (In reply to comment #45)
> > I think the reason the imap log looks that way is that we never clean up the
> > cached connections, i.e., the shutdown process fails before then. And you have
> > cleanup inbox on exit selected, but I don't see us issuing the expunge on the
> > inbox either. In your new profile, did you select cleanup inbox on exit?
> 
> Deselecting "cleanup inbox on exit" in my primary profile does work around the
> problem; it's exited cleanly five times in a row now. 

FWIW I NEVER had "cleanup inbox on exit" selected.  So at least for my reports
cleanup exit should never have been a factor.  OTOH, my problem (which has gone
away) may not have the same root cause as others.  
I've been able to recreate a problem like this a few times, by turning on empty
trash on exit, and cleanup inbox on exit, on my imap account that supports IDLE.
 What's happening is that when we finish the url, we're sending the IDLE command
but not waiting for the response, because we handle that response
asynchronously. But, in some situations, we immediately try to get out the IDLE
state by sending a DONE, before we've received the "+" response from the IDLE
command. This causes all sorts of confusion, probably on the server, and in our
imap parser. This is a general problem with our IDLE handling, but doing stuff
on exit exposes it.

There are a couple possible fixes - one is not to go into IDLE mode when we're
shutting down, and the other is to parse the IDLE "+" response synchronously
before returning from the URL. The latter is probably sufficient, but they're
both worthwhile, so I'll try to do both.
Assignee: mscott → bienvenu
that's not quite right - we do parse the IDLE response synchronously, but the
imap thread tells the ui thread that it's finished with the URL before we even
send the IDLE command. In the shutdown cleanup case, we try to shutdown the
connection right after the URL is run, which includes ending the IDLE command.
But this can happen before we've entered the IDLE state. This is only a problem
in the shutdown cleanup case because in that case the UI thread uses the imap
protocol object directly, instead of running a url. 
This attempts to fix the race condition between going IDLE and shutting down,
by using a monitor. In effect, it makes us wait for the IDLE response to be
parsed before trying to close down the connection.  I'm still working on making
shutdown urls not take us IDLE since that will speed up shutdown, but this
fixes the general case for me, and is required anyway for the case where the
user closes the app just as we're going IDLE. Scott, you might want to try
running with this, since you've been bit by this shutdown hang before - you
might want to turn on one or more of the exit cleanup settings as well.
Attachment #183516 - Flags: superreview?(mscott)
Attachment #183516 - Flags: superreview?(mscott) → superreview+
Attachment #183516 - Flags: approval-aviary1.1a1?
Thanks! 

I'm not very familiar with the Mozilla release process, so let me know if
there's a particular build you'd like me to test against. (I tried
2005-05-16-trunk and the process is still hanging around.)

   Josh

I haven't got approval to check this fix in - when I do, I'll mark it fixed and
then you can try the build that comes out the next day.
Comment on attachment 183516 [details] [diff] [review]
fix for the imap empty trash/cleanup inbox on exit case

a=asa
Attachment #183516 - Flags: approval-aviary1.1a1? → approval-aviary1.1a1+
fix checked in - this should fix the imap case. I don't have a reproducible case
for any other instance of this bug (e.g., if you're using a pop3 server). But,
Josh, you can try a trunk build from tomorrow, Friday, May 20th, and see if the
problem is fixed for you.
*** Bug 288933 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Getting this bug often with pop3 server also. Isn't there or wasn't there a bug
to give feedback that the program was already running? Maybe in Firefox or
Mozilla. It at least told you that another instance was running so you weren't
sitting there waiting like a dummy.
(In reply to comment #54)
> Josh, you can try a trunk build from tomorrow, Friday, May 20th, and see if the
> problem is fixed for you.

I've been using 25-May trunk for a couple days now (at least a dozen starts and
exits), and haven't seen any hangs. Looks good!
Whenever I compose or reply to an email, Thunderbird does not close the sending
mail or compose window. When it finally does the compose section still remains
open in the tool bar.  When I close it from the task manager, the entire
Thunderbird closes.
(In reply to comment #56)
> Getting this bug often with pop3 server also. Isn't there or wasn't there a bug
> to give feedback that the program was already running? Maybe in Firefox or
> Mozilla. It at least told you that another instance was running so you weren't
> sitting there waiting like a dummy.

not in any of the 3 apps that I can find (at the time that you wrote this). 
perhaps you are thinking of bug 156775 or the numerous bugs that comment on it.

however, see new bug 295693 re: FF notification
Flags: blocking-aviary1.5? → blocking-aviary1.5-
(In reply to comment #54)
> fix checked in - this should fix the imap case. I don't have a reproducible case
> for any other instance of this bug (e.g., if you're using a pop3 server). But,
> Josh, you can try a trunk build from tomorrow, Friday, May 20th, and see if the
> problem is fixed for you.


Mark as FIXED?
(In reply to comment #60)
The original problem is fixed for me, at least; I haven't seen this problem for
the past two months.
*** Bug 280287 has been marked as a duplicate of this bug. ***
Recent nightlies have started to exhibit this behaviour for me.
I posted this information in Bug 280287 before it was marked as a duplicate. I 
am posting it here (with modifications) so this instance of the bug can be 
addressed.

Build Identifier: version 1.6a1 (20051010)
Reproducible: Always

Steps to Reproduce:
1. Open Thunderbird.
2. (optional) Set Thunderbird to work offline. This eliminates any potential 
connectivity issues as possible causes.
3. Open a message compose window; for example, by pressing ctrl+n.
4. Close the compose window.
5. Exit Thunderbird.
6. Check the task manager for instances of Thunderbird.

Actual Results:
Thunderbird is still running, even though the GUI is closed.

Further Notes:
Even though the process is still running, launching Thunderbird again brings 
the GUI back to the inbox as it normally does on startup. There is still only 
one instance of the process, so it appears the process is not frozen.
Also, if Thunderbird is configured to ask for offline/online status on startup, 
launching Thunderbird again if the process has not exited correctly does not 
request offline/online status as it normally would. Instead, it just returns 
the GUI directly to the inbox.

I initially thought this was related to Bug 311223, as that bug relates to 
compose window issues, and Thunderbird only fails to exit properly for me after 
a compose window has been opened. Also, Bug 311223 is not reproducible for me 
in Thunderbird 1.5b2, nor is the bug discussed here. However, in the 20051010 
trunk build, this bug occurs but Bug 311223 appears to be resolved for me.
I was experiencing this problem up until the 20051013 nightly.
WFM 
version 1.6a1 (20051013)
Windows XP


The issue I described in comment #64 is resolved for me in latest trunk build (Thunderbird version 1.6a1 (20051108)). Thanks.
WFM now using latest nightly
version 1.6a1 (20051102)
The more recent problem also WFM version 1.6a1 (20051109) on XP

(In reply to comment #54)
> fix checked in - this should fix the imap case. I don't have a reproducible
> case
> for any other instance of this bug (e.g., if you're using a pop3 server). But,
> Josh, you can try a trunk build from tomorrow, Friday, May 20th, and see if the
> problem is fixed for you.

I think Josh replied affirmative, so this can closed fixed?
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Hetz, fixed?
(In reply to comment #69)
> Hetz, fixed?

FWIW Hetz never posted since his report and mail to his address isn't delivered


> I think Josh replied affirmative, so this can closed fixed? 

I'm still on 1.5 Beta 1 (20050908), but yes, it's been fixed for me since May or June 2005. 
I've been seeing this behavior in TB 1.5.0.2, only it seems to only happen after TB has been open for quite a while.  The other thing that bothers me is that when this happens, the thunderbird.exe process seems to peg the CPU.  If i let it sit there long enough (TB windows closed, but process still hanging around) the process eventually goes  away, but at times this is several minutes of waiting.

Is there something that's happening after you close all the TB windows that the process is needing to use so much CPU and needs to continue to hang around for so long?
Hate to dredge up old stuff, but My TB 1.5.0.9 is exhibiting this exact behaviour with one of my IMAP accounts. Sometimes, long after I've closed TB, I get an error saying it can't connect to one of the servers. Other times, there's just a zombie process hanging around in task manager that must be killed before another copy of TB can be loaded. It only seems to affect one of the three IMAP accounts I have configured, which is odd, since they all reside on the same hosting service and are configured exactly the same excepting username/password.

I do not have expunge inbox checked, and I do have cleanup trash on exit checked...

If it is "fixed" then why am I still getting this with 1.5.0.9?
.0.x releases are for security fixes - there are fixes for related issues that are just in 2.0
Thanks.... I was mainly going by those saying the 1.5 versions were working, but if it is in 2.0 that will be good.
Just installed Beta2 late yesterday, and it left a zombie process hanging right at the install.
You need to log in before you can comment on or make changes to this bug.