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?
Created attachment 17168 [details]
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.
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?
Created attachment 23695 [details] [diff] [review]
patch that fixes the message-compose leak, but not the main mail window leak
Created attachment 23702 [details] [diff] [review]
patch that may help main mail window leak, since it makes the crash in bug 65798 reliable
Taking this bug since I've been working on it.
Created attachment 24721 [details] [diff] [review]
I should add, I'm assuming you only want r= on the last patch?
email@example.com. Only thought is to subroutine so that CleanUp and
SetDocShell both call a BreakCycles method (or a better-named one). Your call.
Created attachment 25535 [details] [diff] [review]
fix for leak in main mail window
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...
Created attachment 25701 [details] [diff] [review]
same patch with a comment explaining why
dbaron, you need to patch text area and input element as well, since they have
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.
Created attachment 62196 [details] [diff] [review]
old patch that I removed from my tree that doesn't help anything (?)
dbaron, is this still reproducible?
This is ancient and probably not relevant any more.
based on comment 23, fixed