marking msg read or unread or flag/unflagged consumes 20K of memory

VERIFIED FIXED in mozilla0.9.1


18 years ago
11 years ago


(Reporter: Bienvenu, Assigned: Bienvenu)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+])


(2 attachments)



18 years ago
Everytime I mark a local message read or unread, or flagged/unflagged, it
consumes 20K of memory per message. Not sure if it's because of the outliner
drawing or clearing the icon, or if something in the mail/news backend (e.g.,
updating the mozilla status flag) is consuming the memory. Need to investigate.

Comment 1

18 years ago
this is true of local msgs and not of imap msgs, so it's not an outliner
problem. It may have to do with committing the mork database (god, I hope that's
not the problem!).

Comment 2

18 years ago
it does seem that commiting the db's consumes the memory; if I comment that out,
the memory isn't consumed. It may not be a leak per se, but rather, bloat.
Still, mork commits should not consume memory so nominating for beta.
Keywords: nsbeta1

Comment 3

18 years ago
I'm marking nsbeta1+ because I'm assuming it means when reading messages to. It 
seems like this could lead to large bloat pretty quickly. What about news?
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1

Comment 4

18 years ago
local mail is the worst because each flag toggle does a session commit, which
seems to consume a fixed 20K. The other protocols (news and imap) don't do
commits as often, and when they do, they do large commits, which don't consume
as much memory. I've got a change in my tree to not do session commmits for
local mail, which will ameliorate some of the damage. But this does need to be
looked into.

Comment 5

18 years ago
Created attachment 31261 [details] [diff] [review]
proposed fix

Comment 6

18 years ago
Mork has a feature where you can associate an allocator with an env, and I used
this feature with the environment created by the panacea.dat mork db - the
allocator I used was a pool allocator which I freed up all at once at the end.
BUT, it turns out that mork was using the pooling allocator for db's other than
the folder cache (grrr...) so I'm going to stop using the pooling allocator
completely. It was probably a bad idea in the first place, but it did prevent
memory leaks. (I used it for the folder cache because we keep that open the
whole time mail news is up, so we might as well free it up all at once.) The
patch just stops creating and using the pool. I'll clean it up some more after I
do some testing.

Comment 7

18 years ago
Created attachment 31560 [details] [diff] [review]
fix to completely remove offending code

Comment 8

18 years ago
if it works, r=naving

if this will introduce any leaks, can you log (or re-open) bugs on those leaks? 

Comment 10

18 years ago
it might cause leaks to suddenly appear, but it won't create any new real leaks
because we were using an arena before, which gets freed up in one fell swoop
when we shut down.

Comment 11

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

Comment 12

18 years ago
Using build 2001-05-14 on win I compared the memory usage between this build and 
a build where the problem was reported.  On the 4-10 build, there was a constant 
memory usage change when marking msgs as read or unread in the local folder.  I 
then watched the memory usage for the same scenario with today's build on 
windows.  The memory usage did not change every time I changed the unread/read 
status of messages.  If I need to test this another way please reopen and give 
steps.  Verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.