bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

leaking the Firefox window when run with about:blank or file: command line parameters

RESOLVED DUPLICATE of bug 383269

Status

()

Core
DOM
RESOLVED DUPLICATE of bug 383269
11 years ago
11 years ago

People

(Reporter: roc, Assigned: peterv)

Tracking

({memory-leak})

Trunk
x86
Mac OS X
memory-leak
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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?

Updated

11 years ago
Keywords: mlk
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...
Summary: leaking the Firefox window on every run → leaking the Firefox window when run with about:blank or file: command line parameters
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]
No idea when it started, sorry.
Are we pretty sure the about:blank thing is the only way to trigger this leak?
Not at all. That's just the only way I know to trigger it right now.
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

11 years ago
Created attachment 266468 [details] [diff] [review]
v1

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?
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

11 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

11 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.
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

11 years ago
Do you mean to remove all properties of the global object, or something else?
Yeah, that. I think. I'm shooting in the dark
(Assignee)

Updated

11 years ago
Attachment #266468 - Flags: review?(tony)

Comment 14

11 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

11 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

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 383269
Flags: wanted1.9+
Whiteboard: [wanted1.9]
You need to log in before you can comment on or make changes to this bug.