Closed Bug 87040 Opened 23 years ago Closed 23 years ago

Leaks in creating new mail message

Categories

(MailNews Core :: Backend, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: dprice, Assigned: dbaron)

References

Details

(Keywords: memory-leak)

Attachments

(7 files)

set XPCOM_MEM_LEAK_LOG=\filename
start mozilla -mail                 Size = 39,312K
ctrl-M to start a new mail message  Size = 45,556K
close mail message                  Size = 44,684K
ctrl-M to start a new mail message  Size = 45,860K
close mail message                  Size = 45,304K
ctrl-M to start a new mail message  Size = 46,404K
close mail message                  Size = 45,708K
exit

Our size keeps going up as we create and cancel new mail messages.
Simply starting with -mail and exiting, the leaklog tells me it's leaking 48K
After starting with -mail and canceling one new message it's leaking 1186K
After starting with -mail and canceling three new messages it's leaking 1489K

According to the leak log we leak 25 instances of nsDocument and the largest
standouts by size are... 
nsCSSSelector       77K
nsStr               77K
CSSDeclarationImpl  93K
nsXULAttribute     192K
nsXULAttributes    122K
nsXULElement       172K
keywords += mlk
Keywords: mlk
-> putterman

I'm available to help/answer questions.
Assignee: dprice → putterman
Target Milestone: --- → mozilla0.9.3
reassigning to ducarroz.
Assignee: putterman → ducarroz
Target Milestone: mozilla0.9.3 → mozilla0.9.4
boy it would be good if we could nail some of this mail leaks in the next week.
Blocks: 91387
waterson and I poked at this for a bit last night, and didn't get very far.

We did manage to figure out what was needed to reproduce this.  It requires
focusing something in the mail compose window.  Starting with
"./mozilla -P <PROFILE> -compose"
one must focus something in the mail compose window.  (This seems to happen
automatically for some people, but not for me.)  If I don't focus anything, I
don't see the leak.  If I focus the from dropdown, the attachments widget, any
of the address fields, the subject line, or the message body editor, I see the leak.

It seems like the leak might be related to some ownership cycle that goes
through XPConnect.  There was a nsXULPrototypeAttribute::mEventHandler root that
wasn't unrooted, but it didn't seem to be rooting much in the GC, although
GC_MARK_DEBUG didn't seem too helpful.  The other strange thing was that there
were 2 leaked references but the imbalance in references that had cycles through
XPConnect looked like it was an imbalance of 3.
Bug 93146 explains the leaked roots I was seeing, which may or may not be the
cause of this leak.
The leaks are really from an nsEventStateManager - it's mDocument (I wish that
were an nsCOMPtr) and its gLastFocusedDocument.
The nsEventStateManager is leaked by the nsPresContext.  The nsPresContext is
leaked by 3 different imgRequestProxy (why do they own it?).

The nsEventStateManager, nsPresContext, and imgRequestProxy are among the 14K of
leaks that I see when I don't focus anything.  So it's a small leak that gets
much bigger when the user focuses something.
cc'ing pavlov. could you vend us a clue here, sir?
And the imgRequestProxy are somehow leaked from an nsImageBoxFrame (there are 6
frames leaked).  So some frame isn't destroying its children properly.  (Or
anonymous children, or something.)
I suspect this is related to the assertions:

###!!! ASSERTION: not a container: 'nsnull == aChildList', file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrame.cpp, line 365
###!!! Break: at file
/builds/seamonkey/mozilla/layout/html/base/src/nsFrame.cpp, line 365
This fixes it:

Index: nsCSSFrameConstructor.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,v
retrieving revision 1.609
diff -u -d -r1.609 nsCSSFrameConstructor.cpp
--- nsCSSFrameConstructor.cpp   2001/07/25 07:52:19     1.609
+++ nsCSSFrameConstructor.cpp   2001/08/02 04:22:08
@@ -5479,7 +5479,6 @@
       } // End of RESIZER CONSTRUCTION logic
 
       else if (aTag == nsXULAtoms::image) {
-        processChildren = PR_TRUE;
         isReplaced = PR_TRUE;
         rv = NS_NewImageBoxFrame(aPresShell, &newFrame);
       }
Righteous. r/sr=waterson
This is great.  Thanks David.  Did this fix all of the leak originally reported?
 Adding Varada.  We should update the numbers we're keeping track of after this
goes in.
Who is trying to add a child to an <image> tag.  While I think this patch is
correct, I'd also like to see the bad XUL corrected.
It was something related to bringing in editorOverlay.xul, but I didn't get
beyond that.
hewitt's document inspector could presumably be used to find out the id and type
of the element being placed under the <image> in the content model.  lxr could
find that element, and then we could fix this in the content model as well.


which probably explains why it only happens in the modern skin, varada?
sr=hyatt
r=pavlov to both patches
Taking
Assignee: ducarroz → dbaron
Fix checked in (nsCSSFrameConstructor.cpp), 2001-08-02 19:41 PDT.

Filed bug 93359 on getting the XBL fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 93393 has been marked as a duplicate of this bug. ***
QA Contact: esther → stephend
Since I'm not leaking any |nsXULElement|s, |nsXULAttributes/nsXULAttribute|, 
|CSSDeclarationImpl| or |nsCSSSelector| classes, can I mark this verified?  
This was with a current debug trunk CVS build.  I'm assuming the leakage of 
|nsStr| is either known, or can be filed seperately, since the patches were 
meant to address the XUL/CSS leaks.  Thanks.
verified fixed, see my criteria, above.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: