long freeze when Mozilla Mail loses connection to IMAP server and reconnects memory is leaked in stairway to heaven pattern



15 years ago
10 years ago


(Reporter: aslom, Assigned: Bienvenu)


Windows XP

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

freezez and leaks around 100MB during 60 seconds
when IMAP/SSL conneciton is lost

Reproducible: Always

Steps to Reproduce:
1. use IMAP server over SSL with 10+ folders and thousands of messages
2. waituntil mozila loses connection
3. when reconnecting by doing offline/online mozilla freezes for dozen seconds
(around 40-60secnds inmy case)

Actual Results:  
memory usage increased by about 100MB

Expected Results:  
do not leak memory

after restarting mozilla memory is reclaimed
thesameproblemis in current Thunderbird 0.1

Comment 1

15 years ago
Created attachment 129342 [details]
example of stairway to heaven effect

captured on windows XP SP1 after  mozilla froze for 40 seconds
when reconnecting to IMAP server

Comment 2

15 years ago
I'll look into it. Why does Mozilla lose the connection? And you shouldn't need
to go offline+online again to re-establish the connection, because I put in some
code that 99% of the time should detect when the server has dropped the
Ever confirmed: true

Comment 3

15 years ago
i am at remote location accessing my univesity email 
account using SSL but i think i had the same problem 
in past when i was at university. i am surprised nobody has
reported this problem before - i waited until mozilla 1.4 is
final bit nothing chnaged and moreover i checked that the
same problem is with thunderbird 0.1.

also sometimes switching mozilla mail online/offline 
will lead to the same behavior: mozilla mail client freezes
and memory increase in stairway pattern.


Comment 4

15 years ago
Created attachment 129366 [details] [diff] [review]
proposed fix

I believe the bloat is from opening all the mail db's for folders that might
have offline events to try to playback offline events, but not closing them.
The locking up of the UI is probably because we were opening the db's for
folders that were merely configured for offline use, but didn't have a flag set
saying they had offline events. If there were several large folders like that,
we'd end up opening them synchronously, because it's the playing back of
offline events that introduces asynchronicity.

I need to convince myself that it's OK to only look at folders with the
OFFLINE_EVENTS flag set. I believe it is, and it would be a performance win if
you have lots of large folders configured for offline use, but don't often have
offline events in them.

Comment 5

15 years ago
Created attachment 129369 [details] [diff] [review]
proposed fix, v2

No need to clear the msg database in two places.
Attachment #129366 - Attachment is obsolete: true


15 years ago
Attachment #129369 - Flags: superreview+
Comment on attachment 129369 [details] [diff] [review]
proposed fix, v2

r/a=sspitzer for 1.5 beta
Attachment #129369 - Flags: review+
Attachment #129369 - Flags: approval1.5b+

Comment 7

15 years ago
fix checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 8

15 years ago
that is great! 

Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.