Closed Bug 56703 Opened 24 years ago Closed 13 years ago

leak global object, etc., in main mail window


(Core :: XUL, defect, P3)






(Reporter: dbaron, Assigned: dbaron)


(Keywords: memory-leak, Whiteboard: [MemShrink])


(7 files)

I'm filing this as a toolkit bug rather than a mail bug because I strongly
suspect it's a toolkit problem.

Opening the main mail window (run "mozilla -mail", and exit) leaks a
GlobalWindowImpl that is not garbage collected.  There is a single leaked JS
root: an nsXPCWrappedJS (that is an nsIController).  It is leaked from an
nsXULControllers object (it is inserted into that objects supports array and
never removed).  The leaked nsXULControllers object is leaked from a
GlobalWindowImpl.  This seems like a simple circular reference problem that
should be fixed by adding |mControllers = nsnull; // Forces release| to
|GlobalWindowImpl::CleanUp|.  However, that doesn't fix it.  I have no idea why?
Where did I go wrong?
A few more thoughts.  I previously thought that CleanUp was called because the
window's script object was not rooted.  However, it could be that the window's
script object was never requested.  (How much could such a window be used? 
Maybe it was some sort of prototype?)

The mControllers=nsnull might be a good idea anyway, whether it's the problem
here or not.  I think once in the past I saw it reduce the fallout from another
The changes for bug 55426 may make this harder to detect.
->danm for investigation. Please nominate for rtm or future as appropriate.
Assignee: trudelle → danm
Target Milestone: --- → mozilla1.0
I'm seeing a very similar leak in the message compose window.
Hmmm, nsHTMLInputElement and nsHTMLTextAreaElement also have an
nsXULControllers.  I bet that's the problem.  If so, is releasing it on
SetDocument(null) the right solution?
It didn't work because nsGfxTextControlFrame2::Destroy calls GetControllers.  At
least, that's why fixing the nsXULControllers leaked from the input element
didn't work.  I still don't know if that's the cause of the bigger leak.
Well, I fixed the leak of the nsXULControllers from the input element (by adding
a SetControllers method and calling it in nsGfxTextControlFrame2::Destroy), and
the rest of the leak didn't go away, so the cycle is through the
nsXULControllers object that is the mControllers of the GlobalWindowImpl.  So
what's wrong here?  Is GlobalWindowImpl::Close() not being called?
Taking this bug since I've been working on it.
Assignee: danm → dbaron
Priority: P3 → P2
Target Milestone: mozilla1.0 → mozilla0.9
Nice. r=waterson
I should add, I'm assuming you only want r= on the last patch?  Only thought is to subroutine so that CleanUp and
SetDocShell both call a BreakCycles method (or a better-named one).  Your call.

Hmm.  Perhaps a more general fix for this type of leak would be to set
mDocument to null in GlobalWindowImpl::SetDocShell.  This might break
a lot of potential cycles, but I'm not sure whether it would break all
the ones we need to break...
dbaron, you need to patch text area and input element as well, since they have
controllers also.

sr=hyatt on the XULElement, but please make the same patch to the other elts
before checking in.
Never mind.  Odds are slim it would become a problem.  Fire away.
Fix for nsXULElement checked in 2001-03-09 19:18 PST.  I need to investigate
whether we need a:
 * Input/TextArea fix
 * general fix in GlobalWindowImpl
so leaving the bug open for now.
Moving to 0.9.1 for dealing with the remaining issues.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → Future
Blocks: 92580
No longer blocks: 92580
Summary: leak global object, etc., in main mail window → used to leak global object, etc., in main mail window
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
dbaron, is this still reproducible?
Whiteboard: [MemShrink]
This is ancient and probably not relevant any more.
Closed: 13 years ago
Resolution: --- → WONTFIX
based on comment 23, fixed
Resolution: WONTFIX → FIXED
Summary: used to leak global object, etc., in main mail window → leak global object, etc., in main mail window
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.