Closed Bug 748966 Opened 12 years ago Closed 12 years ago

Many ghost windows/compartments with MemBench?

Categories

(Firefox :: Untriaged, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mccr8, Unassigned)

Details

(Whiteboard: [MemShrink])

IDEVFH reported in IRC experiencing a huge number of ghost windows and zombie compartments in MemBench.

[1:49pm] IDEVFH joined the chat room.
[1:58pm] IDEVFH: Testing Nightly 15.0a1 (2012-04-25) Thoroughly confused with the MemShrink last report of memory efficiency improvements.
[1:59pm] IDEVFH: My test findings have been showing significant amount of orphaned and ghostly residuals shown in both about:compartments and about:memory?verbose.
[1:59pm] IDEVFH: Anyone else experiencing same ?
[2:01pm] IDEVFH: My tests are running with new profile and NO add-ons and the 3 plugins are disabled.
[2:02pm] mccr8: IDEVFH: what sort of ghost windows are you seeing?  It is not a perfect detection system, and it can turn up some false negatives.
[2:03pm] mccr8: For instance, if you go to Facebook, then some kind of Facebook CDN can show up, because it isn't in quite the same domain.  Or something like that.
[2:06pm] IDEVFH: mccr8: Using the MemBench http://gregor-wagner.com/tmp/mem - after the openings I wait about 20mins then followed by GC CC 3x then followed by closing all opened then waiting 20 mins with the same 3x GC CC. I'll post my last results. Give me a moment and I do the posted findings
[2:06pm] mccr8: IDEVH: okay thanks!
[2:06pm] mccr8: that sounds like a good concrete test case we can investigate.  
[2:08pm] IDEVFH: mccr8: Findings http://pastebin.mozilla.org/1597285
[2:09pm] mccr8: IDEVH: I guess about:compartments is including all of the same stuff?
[2:09pm] mccr8: We should file a bug about this.  Do you want to file it or should I?
[2:10pm] IDEVFH: mccr8: Finding for the about:compartments http://pastebin.mozilla.org/1597295
[2:10pm] mccr8: thanks

As for the contents of about:compartments, there are almost 200 zombie compartments and about 300 ghost windows.  I'm not sure if there isn't enough time being allowed for things to settle out or if MemBench is doing something weird.
mccr8: IDEVFH: How long after you close all of the windows did you wait before taking measurements?
[2:18pm] mccr8: Maybe things are just staying alive for a few minutes?
[2:19pm] IDEVFH: mccr8: 45mins with the hope the GC CC would release the compartments and ghosteries.
OS: All → Windows 7
Hardware: All → x86_64
MemBench is the framework we use for AWSY, right?  If so, I doubt that's what's causing these leaks.
I think AWSY uses some weird Python test harness and isn't just a regular web page.  I could be wrong.
(In reply to Andrew McCreight [:mccr8] from comment #3)
> I think AWSY uses some weird Python test harness and isn't just a regular
> web page.  I could be wrong.

You're right about that.  I thought "MemBench" was a similar thing, but apparently not.  I can't keep all these "Mem*" things straight.
This is just a bug in MemBench.  It keeps a reference to every window it opens (so it can close it).

    windows[n] = window.open(sites[n]);
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
jlebar found that the problem is that MemBench keeps a reference to all windows in an array:

if (windows[i])
  windows[i].close();

Thus we leak everything.  Gregor, maybe you could change it so that it nulls out the windows[i] after it closes it?
Yesterday, I ran using the MemBench http://gregor-wagner.com/tmp/mem leaving the ( User Compartments ) windows orphan upon closing.

I discovered that in the about:config setting ( dom.allow_scripts_to_close_windows ) is by default ( FALSE ).

I set ( dom.allow_scripts_to_close_windows ) to ( TRUE ) and limited the windows opened with the MemBench. After starting the closing URLs there where no ( User Compartments )orphan windows listing.

I tried running the full test but there must be some additional issues with the MemBench besides this about:config setting.

Maybe the about:config setting ( dom.allow_scripts_to_close_windows ) is by default ( FALSE ) is causing some issue with the add-ons as well. Just a thought. I haven't validated yet with any add-ons.

Has this setting been considered for the orphaned ( User Compartments ) being present ?
(In reply to Andrew McCreight [:mccr8] from comment #6)
> jlebar found that the problem is that MemBench keeps a reference to all
> windows in an array:
> 
> if (windows[i])
>   windows[i].close();
> 
> Thus we leak everything.  Gregor, maybe you could change it so that it nulls
> out the windows[i] after it closes it?

Yeah I can change that. I also suggest to close the benchmark tab at the end.
Gregor Wagner [:gwagner] - Thank you !

I intend to do some more testing MemBench to what else is causing the orphans when a user doesn't close the Tab as you've suggested. Out of the 150 URLs there seems to be something else going on and I'm curious to the why ?
Completed my test with MemBench with a localized version with the mod for nulling out windows. Previously, I set( dom.allow_scripts_to_close_windows ) to ( TRUE ). Launched MemBench URLs followed by closing from MemBench all opened windows resulted in the ( User Compartments ) showing all Tabs closed properly with no orphans. The only ( Ghost Windows ) showed from the popup windows from the various websites opened in MemBench. After closing, waited 20mins using GC, CC, and Minimize memory usage, Nightly normalized down from the testing start-up: ( Working Set 122,540k ) to finalizing testing: ( Working Set 397,736k ). Nightly's is definitely improving.

Gregor Wagner [:gwagner] if you could change your site code with the windows null then a test user would have to watch for the popups followed by closing them for a good test run.
Gregor Wagner [:gwagner] Tested 04-28-12 with your modification to MemBench site. I found testing successful when closing all opened URLs with Nightly 15.0a1 (2012-04-28 ) normalizing memory as expected. Just remind test users to manually close any additional popup windows to complete test.
(In reply to IDEVFH from comment #11)
> Gregor Wagner [:gwagner] Tested 04-28-12 with your modification to MemBench
> site. I found testing successful when closing all opened URLs with Nightly
> 15.0a1 (2012-04-28 ) normalizing memory as expected. Just remind test users
> to manually close any additional popup windows to complete test.

Thanks for testing! I will put this on my page.
(In reply to Justin Lebar [:jlebar] from comment #5)
> This is just a bug in MemBench.  It keeps a reference to every window it
> opens (so it can close it).
> 
>     windows[n] = window.open(sites[n]);

i don't see how this is a bug in membench once all the tabs/windows including its own AND the window is closed in favour of a new window being opened

in this case, i still see a single completely random ghost window/zombie compartment up to 30 minutes after creating the new window and closing the old.
> i don't see how this is a bug in membench once all the tabs/windows including its own AND the window 
> is closed in favour of a new window being opened

Once you close all the relevant windows, everything should go away, correct.

> in this case, i still see a single completely random ghost window/zombie compartment up to 30 
> minutes after creating the new window and closing the old.

That sounds like a bug, probably in one of your add-ons.  We'd appreciate if you figured out which one is causing the problem (by disabling your add-ons one at a time) and then filed a new bug on this issue.
Wish i could blame extensions, but it was a clean profile with all extensions off.

i pretty much opened nightly with profile manager set to open with a temp profile and executed the membench with paste and go right into the browser.

some of the pages do open plugins however but i don't believe Amazon.com is one of them.

Bing also had a ghost on a subsequent run of membench.

Of course i might be seeing regressions from the latest merge from inbound, so we'll have to see yet.
Please file a separate bug on this issue you're seeing.  Thanks!
You need to log in before you can comment on or make changes to this bug.