Closed Bug 56703 Opened 21 years ago Closed 10 years ago

leak global object, etc., in main mail window

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: dbaron)

Details

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

Attachments

(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?
Attached file leaked objects
Keywords: mlk
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
leak.
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?
Well, it didn't work.
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
Attached patch proposed patchSplinter Review
Nice. r=waterson
I should add, I'm assuming you only want r= on the last patch?
sr=brendan@mozilla.org.  Only thought is to subroutine so that CleanUp and
SetDocShell both call a BreakCycles method (or a better-named one).  Your call.

/be
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...
r=waterson
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
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → Future
Priority: P2 → P3
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.
Status: ASSIGNED → RESOLVED
Closed: 10 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.