Closed
Bug 380837
Opened 18 years ago
Closed 18 years ago
leaking the Firefox window when run with about:blank or file: command line parameters
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 383269
People
(Reporter: roc, Assigned: peterv)
References
Details
(Keywords: memory-leak)
Attachments
(1 file)
674 bytes,
patch
|
tony
:
review+
|
Details | Diff | Splinter Review |
If I start up Firefox from the command line with an "about:blank" command-line parameter, and then immediately quit, 2 nsGlobalWindows are leaked. These are the inner and outer nsGlobalWindows for browser.xul.
Interestingly, if I start up with no command-line URLs, or with any set of command line URLs including at least one http: URL, we don't leak. If I start up with any positive number of command-line URLs consisting entirely of file: or about:blank, we leak. If I start up with about:config, we don't leak, but if I start up with about:config and about:blank, we do leak...
Flags: blocking1.9?
Reporter | ||
Comment 1•18 years ago
|
||
If I turn new-textframe on, we crash in a cairo assert on shutdown instead of just leaking; the leak prevents nsLayoutStatics::Shutdown from running, so my cleanup code never gets to run. I could work around this but crashing when we leak is perhaps no bad thing...
Reporter | ||
Updated•18 years ago
|
Summary: leaking the Firefox window on every run → leaking the Firefox window when run with about:blank or file: command line parameters
Comment 2•18 years ago
|
||
Obviously good to get this fixed, but not a blocker as this wouldn't be much of a problem for average users.
Roc, do you know if this is a regression, and if so, any clue when it started happening? Related to the fix for bug 378987?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted1.9]
Reporter | ||
Comment 3•18 years ago
|
||
No idea when it started, sorry.
Comment 4•18 years ago
|
||
Are we pretty sure the about:blank thing is the only way to trigger this leak?
Reporter | ||
Comment 5•18 years ago
|
||
Not at all. That's just the only way I know to trigger it right now.
Comment 6•18 years ago
|
||
Similar leak is reported to Bug 381992 for Tb 2.0 & latest-trunk of Tb on MS Win.
When Tb, the leak is produced by "simply start Tb & close Tb immediately".
Is this bug Mac OS X only issue?
Assignee | ||
Comment 7•18 years ago
|
||
I'm seeing a leak when starting up and shutting down with a profile with the homepage set to about:blank. This patch fixes it for me. The safebrowsing component keeps a reference to the tabbrowser, which ends up keeping a XUL document alive. By the time the component shuts down and releases its reference, the cycle collector has already shut down and so we don't collect any cycles involving the XUL document. I have no idea why this only happens for about:blank or local files.
Roc: could you try this patch and let me know if it fixes the leak?
Reporter | ||
Comment 8•18 years ago
|
||
This seems to fix things for me.
Is there a way to change shutdown so that the cycle collector runs after all JS components have shut down? It would be nice for JS components and extensions to not be vulnerable to leaks in this way.
Assignee | ||
Comment 9•18 years ago
|
||
(In reply to comment #8)
> Is there a way to change shutdown so that the cycle collector runs after all JS
> components have shut down? It would be nice for JS components and extensions to
> not be vulnerable to leaks in this way.
Bsmedberg?
(This isn't really specific to JS components. though it's probably more likely to happen there because it's harder to spot strong references).
Assignee: general → peterv
Comment 10•18 years ago
|
||
Define "shut down"... JS components really shouldn't be holding XPCOM references forever, they should be nulling them out at xpcom-shutdown *or* holding them alive via XPCOM objects that can be cycle-collected.
We can't really run cycle/garbage collection after we start releasing modules, because you don't have any guarantees that the other module still exists.
See http://wiki.mozilla.org/XPCOM_Shutdown for the "correct" sequence: the only part of that which is unimplemented is xpcom-shutdown-gc.
Reporter | ||
Comment 11•18 years ago
|
||
Could we tear down the JS roots for JS components before we run cycle collection for the last time? Without actually unloading those components?
Comment 12•18 years ago
|
||
Do you mean to remove all properties of the global object, or something else?
Reporter | ||
Comment 13•18 years ago
|
||
Yeah, that. I think. I'm shooting in the dark
Assignee | ||
Updated•18 years ago
|
Attachment #266468 -
Flags: review?(tony)
Comment 14•18 years ago
|
||
Comment on attachment 266468 [details] [diff] [review]
v1
review+, but I don't understand why the XUL tabbrowser causes an xpcom leak.
Random guess: maybe the web progress listeners aren't getting removed properly on DOMWindowClose.
Attachment #266468 -
Flags: review?(tony) → review+
Comment 15•18 years ago
|
||
Better random guess: it may have something to do with about: and file: being flagged as spurious (not checked by phishing) in browser/components/safebrowsing/src/nsDocNavStartProgressListener.cpp.
Does starting firefox with chrome: URLs also trigger the leak?
Assignee | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted1.9]
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•