Last Comment Bug 668871 - (ZombieCompartments) [meta] Zombie Compartments! They stay alive after their tab has closed
(ZombieCompartments)
: [meta] Zombie Compartments! They stay alive after their tab has closed
Status: RESOLVED FIXED
[see comment 43 and 60]
: meta, mlk
Product: Core Graveyard
Classification: Graveyard
Component: Tracking (show other bugs)
: unspecified
: All All
: -- normal with 17 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: chris hofmann
Mentors:
http://blog.mozilla.com/nnethercote/2...
: 646666 (view as bug list)
Depends on: 694689 810344 852832 853046 872526 bc-leaks 669545 669730 669845 670569 671053 671114 672111 672619 672742 673304 674535 677212 679675 685758 688894 691102 691537 ZombieHunter 696213 698018 700830 701477 705705 707403 707507 707524 707879 707964 708071 708260 708591 711391 711675 711778 712733 714509 715474 717549 718168 718273 718375 719782 720591 721319 723843 724273 724361 724377 724404 724433 725223 725603 725875 725956 727552 727739 727938 727953 727974 728008 728034 728525 728528 728589 729378 729423 729608 LA-hyperwords 729948 730546 730566 730682 730683 730784 730796 730846 LA-video-downloader- 731105 LA-scrapbook-plus 731801 731934 732335 732782 734097 734408 735007 LA-picpasso LA-seoquake-seo-exte LA-coknown-research- 737972 740085 740363 741778 742232 742578 742663 743178 743215 743318 743414 745149 747466 748296 752468 752497 752500 752904 754864 758298 758894 764840 766875 LA-searchmenu-search LA-web-developer 778318 781482 788015 795221 795633 811128 818931 835010 835011 1174950 1255998
Blocks: mlk-fx7 MatchStartupMem
  Show dependency treegraph
 
Reported: 2011-07-01 12:15 PDT by Justin Lebar (not reading bugmail)
Modified: 2016-07-15 12:13 PDT (History)
57 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Processed trace (6.67 KB, text/plain)
2011-07-01 13:25 PDT, Justin Lebar (not reading bugmail)
no flags Details
Processed trace (from debug build) (7.29 KB, text/plain)
2011-07-01 14:13 PDT, Justin Lebar (not reading bugmail)
no flags Details
about:memory on OSX (3.06 KB, text/plain)
2011-07-01 14:49 PDT, Andrew McCreight [:mccr8]
no flags Details

Description Justin Lebar (not reading bugmail) 2011-07-01 12:15:48 PDT
I don't know if this is an about:memory bug or a compartments bug.  But in my about:memory, I have tons of compartments from pages I visited a long time ago and tabs I've since closed.

The compartments don't go away when I "minimize memory usage", which does a gc/cc and fires a memory-pressure event (which, among other things, clears bfcache).
Comment 1 Justin Lebar (not reading bugmail) 2011-07-01 12:18:49 PDT
These compartments are reported to be taking up a significant amount of space, too -- tbpl, which I don't have open, is reported to be taking up 17mb.
Comment 2 Andrew McCreight [:mccr8] 2011-07-01 12:26:56 PDT
This tells you how to get a cycle collector graph dump: https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump

With the graph dump, you should look for the nsDocument associated with the compartment you think is leaking.  Then you can use peterv's perl script to find what is holding on to it (bug 466157).  First you reverse the cycle graph, then find the nsDocument you identified in the previous step.
Comment 3 Justin Lebar (not reading bugmail) 2011-07-01 12:45:00 PDT
From a cc dump where the tbpl compartment appeared to be leaking, I verified that the tbpl document exists.  Now to find out what's holding it...
Comment 4 Andrew McCreight [:mccr8] 2011-07-01 12:48:03 PDT
On OSX, I had a bunch of tbpl tabs opened.  When I closed them, they disappeared from about:memory.
Comment 5 Justin Lebar (not reading bugmail) 2011-07-01 13:09:12 PDT
After running peterv's "process the edge log" script, I get

0x7f5b50469a30 nsDocument (xhtml) http://tbpl.mozilla.org/
< 0x7f5b504301c0 mIdentity
< 0x275c1d8 mDocument

What does this mean?
Comment 6 Andrew McCreight [:mccr8] 2011-07-01 13:11:10 PDT
That script just reverses the CC graph as a preprocessing step.  You then need to run the "analyze the edge log" script to actually analyze it.  I think you give it the address you are interested in as an argument, and pipe in the file.  Or maybe the file is an argument, too.
Comment 7 Justin Lebar (not reading bugmail) 2011-07-01 13:23:24 PDT
Thanks.  Usage is

  $ perl analyze.pl <(perl process.pl cc-edges-1.log) 0xdeadbeef
Comment 8 Justin Lebar (not reading bugmail) 2011-07-01 13:25:55 PDT
Created attachment 543490 [details]
Processed trace

Here's the processed trace.  I'm not sure how to read this, but it looks like a dom event listener is keeping this document alive?
Comment 9 Andrew McCreight [:mccr8] 2011-07-01 13:26:11 PDT
Well, the idea is that you dump the output of process.pl into an intermediate log file so you don't have to reverse the graph multiple times if you want to look at multiple addresses. ;)
Comment 10 Andrew McCreight [:mccr8] 2011-07-01 13:33:02 PDT
There are two objects holding onto the document, 0x22679a0 and 0x1e9d0c0.  For the first, 1 out of 3 references are known to the cycle collector, so there are two unknown references keeping the nsXPCWrappedJS (nsIDOMEventListener) alive.  For the second, 45/47 are known.  All of the "--[]->" lines give a path through memory from the root to the document.
Comment 11 Justin Lebar (not reading bugmail) 2011-07-01 13:33:17 PDT
Just reproduced the leak, at least as far as about:memory is concerned, from safe mode.
Comment 12 Andrew McCreight [:mccr8] 2011-07-01 13:39:48 PDT
Notice that the paths are almost identical from the two roots (though the script just gives one possible path, not all of them).  Cutting out all but the last common element in the paths and we get this:

    0x22679a0 [nsXPCWrappedJS (nsIDOMEventListener) [1/3]]
        --[]-> 0x7f5b55052be0 [JS Object (Function) (global=7f5b60ab4088)]
        --[]-> 0x7f5b5509a480 [JS Object (Function) (global=7f5b60ab4088)]
        --[]-> 0x7f5b60ab4088 [JS Object (Window) (global=7f5b60ab4088)]

    0x1e9d0c0 [nsJSContext [45/47]]
        --[mContext]-> 0x275c840 [JSContext]
        --[[global object]]-> 0x7f5b60a07028 [JS Object (Proxy) (global=7f5b60ab4088)]
        --[]-> 0x7f5b60ab4088 [JS Object (Window) (global=7f5b60ab4088)]
Comment 13 Justin Lebar (not reading bugmail) 2011-07-01 14:01:21 PDT
I just ran this on a debug build, and I see:

    0x7fffe16a2ad0 [nsXPCWrappedJS (nsIDOMEventListener) [1/2]]
        --[]-> 0x7fffd2b2cbe0 [JS Object (Function) (global=7fffd8719088)]
        --[proto]-> 0x7fffd87c3b80 [JS Object (Function) (global=7fffd8719088)]
        --[parent]-> 0x7fffd8719088 [JS Object (Window) (global=7fffd8719088)]
        --[onpopstate]-> 0x7fffd114a3f8 [JS Object (Function) (global=7fffd8719088)]

Uh oh.
Comment 14 Nicholas Nethercote [:njn] 2011-07-01 14:04:53 PDT
I was hoping per-compartment reporters would help with exactly this kind of thing! :)

jlebar, can you attach the output of about:memory?
Comment 15 Andrew McCreight [:mccr8] 2011-07-01 14:06:13 PDT
What do you mean by uh oh?

Could you post your steps to reproduce, so other people can try it?
Comment 16 Justin Lebar (not reading bugmail) 2011-07-01 14:09:44 PDT
It's an "uh oh" because I did push/pop state, so I might have caused this mess.  :)

STR are just: Load tbpl.mozilla.com.  Load about:memory.  Close tbpl.  Click "minimize memory usage" (or don't -- it doesn't matter).  I'm on Linux-64.

njn, about:memory looks normal, just with extra compartments which shouldn't be there.  There's no change in the tbpl compartment before or after I close it.
Comment 17 Justin Lebar (not reading bugmail) 2011-07-01 14:13:48 PDT
Created attachment 543507 [details]
Processed trace (from debug build)
Comment 18 Andrew McCreight [:mccr8] 2011-07-01 14:20:28 PDT
I can reproduce this on OSX 64.
Comment 19 Andrew McCreight [:mccr8] 2011-07-01 14:45:10 PDT
This doesn't happen with cnn.com
Comment 20 Andrew McCreight [:mccr8] 2011-07-01 14:49:39 PDT
Created attachment 543519 [details]
about:memory on OSX

about memory, after loading tbpl and about memory, closing tbpl, then hitting minize memory a bunch of times
Comment 21 Andrew McCreight [:mccr8] 2011-07-01 15:15:19 PDT
bz was unable to reproduce this on a previous Nightly.

Another combo I tried:
- load Firefox
- load tbpl.mozilla.org
- open a new tab with about:blank
- close tbpl.mozilla.org
- (do a bunch of other browsing, like techcrunch, slashdot, etc.)
- load about:memory

This resulted in having 2 extra compartments for tbpl and "https://clients6.google.com/static/proxy" etc.  So tbpl sticks around even though I didn't do about:memory until long after it should have gone, and most compartments don't stick around, except this rogue google compartment, which is plusone related.
Comment 22 Andrew McCreight [:mccr8] 2011-07-01 15:18:24 PDT
"bz was unable to reproduce this on a previous Nightly."

He looked for the leaking compartment by examining the CC graph dump, and the nsDocument associated with tbpl didn't seem to be sticking around, I believe.
Comment 23 Nicholas Nethercote [:njn] 2011-07-01 15:20:54 PDT
(In reply to comment #21)
> except this rogue google compartment, which is plusone related.

Did you GC+CC several times or "minimize memory usage"?  Some compartments will legitimately stick around until you do that.
Comment 24 Nicholas Nethercote [:njn] 2011-07-01 15:21:32 PDT
(In reply to comment #22)
> "bz was unable to reproduce this on a previous Nightly."
> 
> He looked for the leaking compartment by examining the CC graph dump, and
> the nsDocument associated with tbpl didn't seem to be sticking around, I
> believe.

Did he see the TBPL compartment in about:memory?
Comment 25 Boris Zbarsky [:bz] 2011-07-01 15:24:08 PDT
> Did he see the TBPL compartment in about:memory?

My build doesn't have that change yet.
Comment 26 Andrew McCreight [:mccr8] 2011-07-01 15:25:16 PDT
I clicked them a ton of times.  It looks like that maybe the compartment goes away eventually?  Is there some kind of time based reason a compartment might be getting held onto, then is released?  Like, tbpl has a bunch of timers where it refreshes the page, so maybe the timer is keeping the page alive, but when it wakes up it sees it should die and goes away?  I'll see what happens to this window in a few minutes.
Comment 27 Andrew McCreight [:mccr8] 2011-07-01 15:26:29 PDT
When I wait a few minutes, then hit minimize memory usage, the tbpl compartment goes away.  This is after spamming "minimize memory usage" to no apparent affect.
Comment 28 Andrew McCreight [:mccr8] 2011-07-01 15:36:17 PDT
It takes between about 2 minutes and 2:20 for the tbpl compartment to go away.

How long is the tbpl refresh timer set for?
Comment 29 Andrew McCreight [:mccr8] 2011-07-01 15:39:08 PDT
It looked like it refreshed after about 2:50.
Comment 30 Andrew McCreight [:mccr8] 2011-07-02 16:07:23 PDT
I noticed a similar thing on Quora (when logged in).
Comment 31 Justin Lebar (not reading bugmail) 2011-07-02 21:40:25 PDT
In my main FF window, I see a compartment for

  https://bug663423.bugzilla.mozilla.org/attachment.cgi?id=543613

even though I haven't opened that attachment in hours.  The compartment doesn't go away when I minimize memory usage.  That page doesn't have any javascript, so whatever is keeping it alive presumably comes from chrome?

When I open that page in a fresh browser, I get a similarly-sized compartment, but it goes away immediately after I close the tab and minimize memory usage.  So maybe somehow this leak happens less often when you have fewer tabs open.

(The tbpl compartment went away after two or three minutes in my clean browser, but it's been here for hours since I closed the tab in my main browser.)

│    ├──────150,972 B (00.01%) -- compartment(https://bug663423.bugzilla.mozilla.org/attachment.cgi?id=543613)
│    │      ├──135,168 B (00.01%) -- gc-heap
│    │      │  ├───58,056 B (00.00%) -- objects
│    │      │  ├───42,304 B (00.00%) -- shapes
│    │      │  ├───31,880 B (00.00%) -- arena-unused
│    │      │  ├────2,136 B (00.00%) -- arena-padding
│    │      │  ├──────792 B (00.00%) -- arena-headers
│    │      │  ├────────0 B (00.00%) -- strings
│    │      │  └────────0 B (00.00%) -- xml
│    │      ├───14,640 B (00.00%) -- object-slots
│    │      ├────1,164 B (00.00%) -- scripts
│    │      ├────────0 B (00.00%) -- string-chars
│    │      ├────────0 B (00.00%) -- mjit-code
│    │      ├────────0 B (00.00%) -- mjit-data
│    │      ├────────0 B (00.00%) -- tjit-code
│    │      └────────0 B (00.00%) -- tjit-data
│    │               ├──0 B (00.00%) -- allocators-main
│    │               └──0 B (00.00%) -- allocators-reserve
Comment 32 Justin Lebar (not reading bugmail) 2011-07-03 15:00:23 PDT
> When I open that page in a fresh browser, I get a similarly-sized compartment, 
> but it goes away immediately after I close the tab and minimize memory usage.  
> So maybe somehow this leak happens less often when you have fewer tabs open.

Actually, it looks like when I have no exte

nsions, all my old compartments time out after a while.  But when I enable my extensions, some compartments stick around for a long time (forever?).  So perhaps there are two separate issues here.

Adblock Plus v1.3.10a.3087
Firebug v1.8.0b4
Bugzilla Tweaks v1.10
telemetry v0.2

I'll bisect later to see which extension is causing the problem.  But the cause is likely bug 669096.
Comment 33 Nicholas Nethercote [:njn] 2011-07-03 16:27:20 PDT
(In reply to comment #32)
>
> Adblock Plus v1.3.10a.3087
> Firebug v1.8.0b4
> Bugzilla Tweaks v1.10
> telemetry v0.2
> 
> I'll bisect later to see which extension is causing the problem.  But the
> cause is likely bug 669096.

My money is on Bugzilla Tweaks and/or Firebug :)
Comment 34 Nicholas Nethercote [:njn] 2011-07-05 20:49:13 PDT
I think the plan for this bug was to make it a tracking bug, and file two dependent bugs, one for the TBPL timer issue, and one for Firebug?
Comment 35 Andrew McCreight [:mccr8] 2011-07-19 07:16:29 PDT
This post from PMO might be interesting for some kind of "Zombie Hunter" code to automatically detect zombie compartments.  Apparently if you have Panorama on you can get a list of currently visible tabs.  Though I guess in that case, we also want the set of hidden-but-still-in-Panorama, but maybe that exists too.

http://antennasoft.net/robcee/2011/07/19/scratchpad-to-get-current-visible-tabs/
Comment 36 Gordon P. Hemsley [:GPHemsley] 2011-07-21 14:27:02 PDT
I'm experiencing these zombie compartments, too. The compartment (for a random BMO bug, rather than TBPL) persists even after the tab has been closed for hours.

The only add-ons I have installed are:
Add-on Compatibility Reporter  0.8.5
Feedback  1.1.2
Mozilla Labs: Prospector - Tab Focus  1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a2) Gecko/20110714 Firefox/7.0a2
Comment 37 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-07-21 14:28:44 PDT
Do you have other bugzilla tabs open?  The compartment just gets assigned the URL of the first one, regardless of whether or not you close that.
Comment 38 Gordon P. Hemsley [:GPHemsley] 2011-07-21 14:31:06 PDT
(In reply to comment #37)
> Do you have other bugzilla tabs open?  The compartment just gets assigned
> the URL of the first one, regardless of whether or not you close that.

Oh, yes, I have a ton of other BMO bugs open. That seems like an odd behavior. What are the criteria for lumping tabs together under a single URL?
Comment 39 Justin Lebar (not reading bugmail) 2011-07-21 14:32:09 PDT
(In reply to comment #38)
> What are the criteria for lumping tabs together under a single URL?

We currently have one compartment per origin, for content.
Comment 40 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-07-21 14:32:30 PDT
(In reply to comment #38)
> (In reply to comment #37)
> > Do you have other bugzilla tabs open?  The compartment just gets assigned
> > the URL of the first one, regardless of whether or not you close that.
> 
> Oh, yes, I have a ton of other BMO bugs open. That seems like an odd
> behavior. What are the criteria for lumping tabs together under a single URL?

Same origin.
Comment 41 Gordon P. Hemsley [:GPHemsley] 2011-07-21 14:41:22 PDT
(In reply to comment #39)
> We currently have one compartment per origin, for content.
(In reply to comment #40)
> Same origin.

Ah, well, it seems to me that the compartments should be named after their shared origin, rather than just the first URL. Filed bug 673248 for that.
Comment 42 Nicholas Nethercote [:njn] 2011-07-21 15:57:55 PDT
http://blog.mozilla.com/nnethercote/2011/07/20/zombie-compartments-recognize-and-report-them-stop-the-screaming/ talks about identifying zombie compartments.  It recommends trying to reproduce the zombie compartment by restarting the browser and opening just the suspect site.
Comment 43 Nicholas Nethercote [:njn] 2011-07-27 17:44:04 PDT
This is a tracking bug now, any zombie compartments found should be reported separately and block this bug.
Comment 44 Nicholas Nethercote [:njn] 2011-08-23 16:43:38 PDT
I've removed the :P1 priority because I'd like to re-prioritize this next meeting, doesn't seem like it needs to be a P1 any more.
Comment 45 Flávio Etrusco 2011-08-25 00:04:46 PDT
Sorry for the noise, I'm just a bystander, but I can't help (not) thinking a page or extension shouldn't be able to leave a compartment leak at any circumstance...
Comment 46 Jesse Ruderman 2011-08-25 00:10:14 PDT
Sure. We are fixing the dependencies :) I try not to pay too much attention to how *meta* bugs are prioritized, because we don't actually work on meta bugs.
Comment 47 Marco Castelluccio [:marco] 2011-08-29 04:36:38 PDT
*** Bug 646666 has been marked as a duplicate of this bug. ***
Comment 48 Aq 2011-12-31 07:27:28 PST
Using Waterfox and looking at verbose about:memory after less than half an hour.
512,570,388 B (100.0%) -- explicit
├──253,072,362 B (49.37%) -- js
...
│  ├───41,909,422 B (08.18%) -- compartment(https://mail.google.com/mail/?ui=2&shva=1#inbox)
│  │   ├──17,813,504 B (03.48%) -- gc-heap
│  │   │  ├───7,821,568 B (01.53%) -- objects
│  │   │  ├───4,043,584 B (00.79%) -- shapes
│  │   │  ├───3,432,960 B (00.67%) -- scripts
│  │   │  ├─────868,992 B (00.17%) -- type-objects
│  │   │  ├─────776,160 B (00.15%) -- arena-unused
│  │   │  ├─────525,408 B (00.10%) -- strings
│  │   │  ├─────205,664 B (00.04%) -- arena-padding
│  │   │  └─────139,168 B (00.03%) -- arena-headers
│  │   ├───8,727,928 B (01.70%) -- analysis-temporary
│  │   ├───4,309,376 B (00.84%) -- script-data
│  │   ├───3,670,016 B (00.72%) -- mjit-code
│  │   │   ├──3,453,256 B (00.67%) -- method
│  │   │   ├────206,040 B (00.04%) -- regexp
│  │   │   └─────10,720 B (00.00%) -- unused
│  │   ├───2,342,184 B (00.46%) -- type-inference
│  │   │   ├──1,732,544 B (00.34%) -- object-main
│  │   │   ├────511,944 B (00.10%) -- script-main
│  │   │   └─────97,696 B (00.02%) -- tables
│  │   ├───2,233,376 B (00.44%) -- property-tables
│  │   ├───1,609,984 B (00.31%) -- object-slots
│  │   ├─────405,536 B (00.08%) -- mjit-data
│  │   ├─────344,142 B (00.07%) -- string-chars
│  │   ├─────304,960 B (00.06%) -- shape-kids
│  │   └─────148,416 B (00.03%) -- object-empty-shapes
│  ├───22,158,984 B (04.32%) -- gc-heap-chunk-dirty-unused
...
│  ├────3,069,344 B (00.60%) -- compartment(about:blank)
│  │    ├──2,801,664 B (00.55%) -- gc-heap
│  │    │  ├────991,272 B (00.19%) -- arena-unused [26]
│  │    │  ├────898,120 B (00.18%) -- objects [26]
│  │    │  ├────820,352 B (00.16%) -- shapes [26]
│  │    │  ├─────38,544 B (00.01%) -- arena-padding [26]
│  │    │  ├─────26,304 B (00.01%) -- type-objects [26]
│  │    │  ├─────21,888 B (00.00%) -- arena-headers [26]
│  │    │  └──────5,184 B (00.00%) -- scripts [26]
│  │    ├────135,072 B (00.03%) -- object-slots [26]
│  │    ├─────62,176 B (00.01%) -- property-tables [26]
│  │    ├─────26,304 B (00.01%) -- type-inference
│  │    │     └──26,304 B (00.01%) -- object-main [26]
│  │    ├─────22,752 B (00.00%) -- shape-kids [26]
│  │    ├─────20,544 B (00.00%) -- object-empty-shapes [26]
│  │    └────────832 B (00.00%) -- analysis-temporary [26]


├───29,264,326 B (05.71%) -- layout
...
│   ├───2,853,328 B (00.56%) -- shell(about:blank)
│   │   ├──2,379,632 B (00.46%) -- styledata [28]
│   │   └────473,696 B (00.09%) -- arenas [28]
│   ├───1,856,936 B (00.36%) -- shell(http://www.teefury.com/)
│   │   ├──1,053,536 B (00.21%) -- arenas
│   │   └────803,400 B (00.16%) -- styledata
How is it an about:blank page is using more memory than the majority of other fully featured pages? Gmail seems to be using a lot of memory for 30mins and 1 sent email.
Comment 49 :aceman 2012-01-05 00:52:41 PST
But where is the zombie in your output?
Was gmail or teefury tab already closed when you looked into about:memory?
Comment 50 Nicholas Nethercote [:njn] 2012-01-05 01:51:20 PST
> │  ├────3,069,344 B (00.60%) -- compartment(about:blank)
> │  │    ├──2,801,664 B (00.55%) -- gc-heap
> │  │    │  ├────991,272 B (00.19%) -- arena-unused [26]
>
> How is it an about:blank page is using more memory than the majority of
> other fully featured pages? Gmail seems to be using a lot of memory for
> 30mins and 1 sent email.

There are 26 about:blank pages.  That's what the "[26]" means.  This can happen if you restore a session that has lots of tabs and you have the "Don't load tabs until selected" option turned on.  Bug 681201 is open to further reduce the cost of each blank page.

But, as comment 49 says -- what does this have to do with zombie compartments?
Comment 51 Aq 2012-01-05 06:42:05 PST
No you're both right. At the time there were no manually created about:blank pages open. I didn't realise that the about:blank pages were from the restore session "Don't load tabs until selected" tabs and don't count as zombie compartments. I figured that about:blank pages shouldn't be using any memory at all since I had closed the ones I used at the time. Thanks for clearing that up. 

Probably unimportant to this specific thread but I've stopped using Waterfox (64bit apparently uses more memory than 32bit) and can now use Memory Fox (AFOM.exe only runs on 32bit windows Firefox) to reduce 1.4GB resident memory usage down to 240MB, using the same number of tabs and addons. I mention this only as a temporary workaround for others who are running out of memory until a proper fix is found.
Comment 52 Nicholas Nethercote [:njn] 2012-01-05 15:32:59 PST
> Probably unimportant to this specific thread but I've stopped using Waterfox
> (64bit apparently uses more memory than 32bit) and can now use Memory Fox
> (AFOM.exe only runs on 32bit windows Firefox) to reduce 1.4GB resident
> memory usage down to 240MB, using the same number of tabs and addons. I
> mention this only as a temporary workaround for others who are running out
> of memory until a proper fix is found.

What does Memory Fox actually do?  I'm skeptical about its effect.  Reducing 1.4GB resident to 240MB sounds... surprising.
Comment 53 Loic 2012-01-05 16:03:17 PST
Yes, these programs like Memory Fox or AFOM are a lie, they just use a standard Windows function to flush the process's memory (oh, what a smart use of garbage collecting) resulting in worse performance because Firefox needs to reallocate the memory to display the pages. And the others just swap memory from RAM to disk, that may be very slow.
Comment 54 Aq 2012-01-05 16:29:56 PST
As to how it does it, I don't know any more than what the website says. It uses a program (AFOM.exe) to "recover fragmented orphaned memory". The effect of using Memory Fox though seems to be an occasional increase in CPU usage. Depending on how fast your computer is, you might experience a few seconds of "Not responding" when it is running or you might get half a second delay typing in text boxes. It also seems to be able to work on other programs other than Firefox.

I wasn't exaggerating the memory usage difference and was surprised the first time I used it. I stopped using it a year or so ago because of the aforementioned occasional downside (and old laptop) but since these newer versions of Firefox seemed to use up so much more memory unnecessarily I thought I'd give it another try. 

Currently I've barely noticed the "Not responding" instances so either a 500MHz faster CPU is making more of a difference than I thought (I now use a 2.5GHz dual core laptop) or the developer has made it a bit more stable. Firefox page loading speed do not seem to be noticeably impaired by AFOM and the memory freed is of practical importance.

According to their Mozilla addon page, the developer sat in on a Memshrink conference too and is eager to help support Memshrink (https://addons.mozilla.org/en-US/firefox/addon/memory-fox/).
Comment 55 Danial Horton 2012-01-07 18:24:02 PST
:\ the facebook like button causes a massive compartment to continue existing well after all facebook pages are closed.

social media is the biggest temporary zombie causer.

│    ├───65.39 MB (04.65%) -- compartment(http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.facebook.com%2FiiNet&layout=button_count&show_faces=false&width=150&action=like&colorscheme=light&height=21)
│    │   ├──35.84 MB (02.55%) -- gc-heap
│    │   │  ├──16.01 MB (01.14%) -- objects
│    │   │  │  ├──10.54 MB (00.75%) -- function
│    │   │  │  └───5.47 MB (00.39%) -- (1 omitted)
│    │   │  ├──10.37 MB (00.74%) -- (4 omitted)
│    │   │  └───9.47 MB (00.67%) -- shapes
│    │   │      ├──7.52 MB (00.53%) -- tree
│    │   │      └──1.95 MB (00.14%) -- (1 omitted)
│    │   ├──11.73 MB (00.83%) -- (6 omitted)
│    │   ├──10.63 MB (00.76%) -- script-data
│    │   └───7.19 MB (00.51%) -- mjit-code
│    │       └──7.19 MB (00.51%) -- (3 omitted)

would be nice if clicking a compartment would take you to a detailed list of whatever is using objects in the compartment, so far i can see dailymotion, youtube and one of my forums affects this facebook compartment by closing down said tabs.
Comment 56 Danial Horton 2012-01-07 18:49:36 PST
opened facebook, this is a 8-12MB compartment

│  ├───9.49 MB (13.27%) -- compartment(http://www.facebook.com/)
│  │   ├──5.66 MB (07.92%) -- gc-heap
│  │   │  ├──2.38 MB (03.33%) -- arena
│  │   │  │  ├──2.33 MB (03.26%) -- unused
│  │   │  │  └──0.05 MB (00.07%) -- (2 omitted)
│  │   │  ├──1.58 MB (02.22%) -- objects
│  │   │  │  ├──0.85 MB (01.18%) -- non-function
│  │   │  │  └──0.74 MB (01.03%) -- function
│  │   │  ├──0.96 MB (01.35%) -- shapes
│  │   │  │  ├──0.69 MB (00.97%) -- tree
│  │   │  │  └──0.27 MB (00.38%) -- (1 omitted)
│  │   │  ├──0.53 MB (00.74%) -- scripts
│  │   │  └──0.20 MB (00.29%) -- (2 omitted)
│  │   ├──1.06 MB (01.49%) -- mjit-code
│  │   │  ├──0.89 MB (01.24%) -- method
│  │   │  └──0.18 MB (00.25%) -- (2 omitted)
│  │   ├──1.01 MB (01.42%) -- (3 omitted)
│  │   ├──0.82 MB (01.15%) -- script-data
│  │   ├──0.54 MB (00.75%) -- type-inference
│  │   │  ├──0.39 MB (00.54%) -- script-main
│  │   │  └──0.15 MB (00.21%) -- (2 omitted)
│  │   └──0.39 MB (00.54%) -- shapes-extra
│  │      └──0.39 MB (00.54%) -- (4 omitted)

opened opened 18 tabs from containing the mangafox homepage (has a facebook share button)

│  ├───77.22 MB (20.33%) -- compartment(http://www.facebook.com/)
│  │   ├──39.33 MB (10.36%) -- gc-heap
│  │   │  ├──16.31 MB (04.30%) -- objects
│  │   │  │  ├──11.12 MB (02.93%) -- function
│  │   │  │  └───5.19 MB (01.37%) -- non-function
│  │   │  ├───9.98 MB (02.63%) -- shapes
│  │   │  │   ├──7.60 MB (02.00%) -- tree
│  │   │  │   └──2.39 MB (00.63%) -- dict
│  │   │  ├───8.60 MB (02.26%) -- scripts
│  │   │  ├───2.13 MB (00.56%) -- type-objects
│  │   │  ├───2.13 MB (00.56%) -- arena
│  │   │  │   └──2.13 MB (00.56%) -- (3 omitted)
│  │   │  └───0.18 MB (00.05%) -- (1 omitted)
│  │   ├──14.27 MB (03.76%) -- script-data
│  │   ├──10.25 MB (02.70%) -- mjit-code
│  │   │  ├───8.74 MB (02.30%) -- method
│  │   │  └───1.51 MB (00.40%) -- (2 omitted)
│  │   ├───4.98 MB (01.31%) -- type-inference
│  │   │   ├──3.17 MB (00.83%) -- script-main
│  │   │   └──1.82 MB (00.48%) -- (2 omitted)
│  │   ├───3.72 MB (00.98%) -- shapes-extra
│  │   │   ├──2.56 MB (00.68%) -- tree-tables
│  │   │   └──1.15 MB (00.30%) -- (3 omitted)
│  │   ├───3.19 MB (00.84%) -- object-slots
│  │   └───1.49 MB (00.39%) -- (2 omitted)

closed the facebook tab, leaving the 18 instances of the mangafox home page open

│  ├───69.77 MB (18.89%) -- compartment(http://www.facebook.com/)
│  │   ├──38.05 MB (10.30%) -- gc-heap
│  │   │  ├──14.74 MB (03.99%) -- objects
│  │   │  │  ├──10.38 MB (02.81%) -- function
│  │   │  │  └───4.36 MB (01.18%) -- non-function
│  │   │  ├───9.15 MB (02.48%) -- shapes
│  │   │  │   ├──7.05 MB (01.91%) -- tree
│  │   │  │   └──2.10 MB (00.57%) -- dict
│  │   │  ├───8.07 MB (02.19%) -- scripts
│  │   │  ├───3.98 MB (01.08%) -- arena
│  │   │  │   ├──3.75 MB (01.01%) -- unused
│  │   │  │   └──0.24 MB (00.06%) -- (2 omitted)
│  │   │  ├───2.01 MB (00.54%) -- type-objects
│  │   │  └───0.09 MB (00.03%) -- (1 omitted)
│  │   ├──13.44 MB (03.64%) -- script-data
│  │   ├───9.56 MB (02.59%) -- mjit-code
│  │   │   ├──8.09 MB (02.19%) -- method
│  │   │   └──1.47 MB (00.40%) -- (2 omitted)
│  │   ├───3.36 MB (00.91%) -- shapes-extra
│  │   │   ├──2.33 MB (00.63%) -- tree-tables
│  │   │   └──1.03 MB (00.28%) -- (3 omitted)
│  │   ├───2.86 MB (00.77%) -- object-slots
│  │   └───2.49 MB (00.67%) -- (3 omitted)

then navigated each of those mangafox tabs to a different manga series from the home page (all 18 on a different page)

│  ├───25.49 MB (09.45%) -- compartment(http://www.facebook.com/)
│  │   ├──17.30 MB (06.42%) -- gc-heap
│  │   │  ├───7.45 MB (02.76%) -- arena
│  │   │  │   ├──7.34 MB (02.72%) -- unused
│  │   │  │   └──0.11 MB (00.04%) -- (2 omitted)
│  │   │  ├───4.37 MB (01.62%) -- objects
│  │   │  │   ├──3.18 MB (01.18%) -- function
│  │   │  │   └──1.19 MB (00.44%) -- (1 omitted)
│  │   │  ├───3.04 MB (01.13%) -- shapes
│  │   │  │   ├──2.45 MB (00.91%) -- tree
│  │   │  │   └──0.59 MB (00.22%) -- (1 omitted)
│  │   │  ├───1.83 MB (00.68%) -- scripts
│  │   │  └───0.61 MB (00.23%) -- (2 omitted)
│  │   ├───3.36 MB (01.25%) -- script-data
│  │   ├───1.64 MB (00.61%) -- shapes-extra
│  │   │   ├──1.35 MB (00.50%) -- tree-tables
│  │   │   └──0.28 MB (00.11%) -- (3 omitted)
│  │   ├───1.63 MB (00.60%) -- mjit-code
│  │   │   └──1.63 MB (00.60%) -- (3 omitted)
│  │   └───1.57 MB (00.58%) -- (4 omitted)

This is from a clean profile in 10b3

surely that facebook compartment on the mangafox home page is excessive.....

in all seriousness, there should be no reason at all for the like or share button to create such a huge compartment period. i could understand if it was a continuously running script but it just sits there useless 99% of the time.
Comment 57 Justin Lebar (not reading bugmail) 2012-01-07 18:53:27 PST
Daniel, this is a metabug; its purpose is to track all the various zombie compartment bugs, not to discuss specifics about any one zombie compartment issue.

Can you please file a separate bug for the issue you're seeing and mark it as blocking this bug?  I'll follow up there.
Comment 58 Danial Horton 2012-01-07 19:14:01 PST
Looks like i won't have to, apparently Luke is already working on it in 690229
Comment 59 Nicholas Nethercote [:njn] 2012-01-11 02:57:40 PST
I'm removing the MemShrink tag, no point having it on a bug when all the blocking bugs also have the MemShrink tag.
Comment 60 Nicholas Nethercote [:njn] 2012-01-11 02:59:24 PST
> http://blog.mozilla.com/nnethercote/2011/07/20/zombie-compartments-recognize-
> and-report-them-stop-the-screaming/ talks about identifying zombie
> compartments.

Better instructions are now available at https://developer.mozilla.org/en/Zombie_Compartments.
Comment 61 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2014-03-05 22:15:33 PST
We have won a great victory over the zombie army.  Rejoice!

Note You need to log in before you can comment on or make changes to this bug.