Closed Bug 303839 Opened 19 years ago Closed 19 years ago

Leaking webshell/domWindow


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: mikepinkerton, Assigned: sfraser_bugs)



(Keywords: fixed1.8, memory-leak, regression)


(1 file, 1 obsolete file)

We're leaking a dom window every time you close the browser window. Not sure
when this regressed.

cc'ing jst in case it's more fallout from the split-window bug.
Target Milestone: --- → Camino0.9
Flags: camino0.9?
Keywords: mlk
Firefox is leaking 2 dom windows for each main window that you create and then
well then!
Assignee: pinkerton → general
Component: General → DOM
Flags: camino0.9?
Product: Camino → Core
QA Contact: ian
Target Milestone: Camino0.9 → ---
Version: unspecified → Trunk
Severity: normal → blocker
Flags: blocking1.8b4?
JST - Split window related?
Assignee: general → jst
Flags: blocking1.8b4? → blocking1.8b4+
Hmm. Seems like Mac only, or anyone see this on non-Mac platforms?
Ok, I actually do see this on win32 and linux as well. This is a leak that crept
in *after* the splitwindow landing, when that change landed, we didn't leak a
single window object after starting firefox and opening another window, and then
closing firefox. 
OS: MacOS X → All
Hardware: Macintosh → All
I see us leaking one document object, the URL loaded into the leaked document is
"chrome://browser/content/feedview/feedview.xsl". There's no JS reference to
that document, so it seems like a leak through C++ code somewhere... digging
Might be related to bug 303043.

Also see bug 303043 comment 8.
Would we get this feedview stuff in Camino?
No idea...
The feedview leaks have been fixed on the trunk and branches, does this leak
still  exist in Camino?
I still see one nsGlobalWindow leaked per main window in Camino when loading a
simple page.

After heavy browsing sessions, I've seen 50-60 windows leaked.
Someone needs to enable GC_MARK_DEBUG to start with to see if we're leaking due
to JS references not being torn down or if it's a C++ leak somewhere. That'd be
where I'd start. Feel free to take this bug, I won't be able to get to a place
where I can debug this any time soon. I can help whoever takes on the task of
finding where this leak is tho...
Simon - is it possible for you to take a swag at this?
Assignee: jst → sfraser_bugs
We're leaking webshells, which entrain dom windows.

I think it may be attributable to this change:

which bryner made.
Summary: Leaking domWindow → Leaking webshell/domWindow
It looks like we have a ref cycle between nsSecureBrowserUIImpl and docShell,
which I don't see being broken anywhere.
Attached patch Patch to break ref cycle (obsolete) — Splinter Review
This patch breaks the ref cycle between the secureBrowserUI/docShell/domWindow.
I'm not sure if this is the best solution.
Attached patch Better patchSplinter Review
Attachment #193596 - Attachment is obsolete: true
Attachment #193614 - Flags: superreview?(bzbarsky)
Attachment #193614 - Flags: review?(bryner)
Attachment #193614 - Flags: review?(bryner) → review+
Seems like this had nothing to do with the split window changes. Updating
No longer blocks: splitwindows
Comment on attachment 193614 [details] [diff] [review]
Better patch

Thanks, Simon!
Attachment #193614 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 193614 [details] [diff] [review]
Better patch

This needs to be fixed on the branch too.
Attachment #193614 - Flags: approval1.8b4?
Attachment #193614 - Flags: approval1.8b4? → approval1.8b4+
Checked into the trunk and branch.
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.