[meta] Zombie Compartments! They stay alive after their tab has closed
Categories
(Core Graveyard :: Tracking, defect)
Tracking
(Not tracked)
People
(Reporter: justin.lebar+bug, Unassigned)
References
(Depends on 3 open bugs, )
Details
(Keywords: memory-leak, meta, Whiteboard: [see comment 43 and 60])
Attachments
(2 files, 1 obsolete file)
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).
Reporter | ||
Comment 1•13 years ago
|
||
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.
Reporter | ||
Updated•13 years ago
|
Comment 2•13 years ago
|
||
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.
Reporter | ||
Comment 3•13 years ago
|
||
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•13 years ago
|
||
On OSX, I had a bunch of tbpl tabs opened. When I closed them, they disappeared from about:memory.
Reporter | ||
Comment 5•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 7•13 years ago
|
||
Thanks. Usage is $ perl analyze.pl <(perl process.pl cc-edges-1.log) 0xdeadbeef
Reporter | ||
Comment 8•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 11•13 years ago
|
||
Just reproduced the leak, at least as far as about:memory is concerned, from safe mode.
Comment 12•13 years ago
|
||
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)]
Reporter | ||
Comment 13•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
What do you mean by uh oh? Could you post your steps to reproduce, so other people can try it?
Reporter | ||
Comment 16•13 years ago
|
||
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.
Reporter | ||
Comment 17•13 years ago
|
||
Comment 18•13 years ago
|
||
I can reproduce this on OSX 64.
Comment 19•13 years ago
|
||
This doesn't happen with cnn.com
Comment 20•13 years ago
|
||
about memory, after loading tbpl and about memory, closing tbpl, then hitting minize memory a bunch of times
Comment 21•13 years ago
|
||
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•13 years ago
|
||
"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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
> Did he see the TBPL compartment in about:memory?
My build doesn't have that change yet.
Comment 26•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
It looked like it refreshed after about 2:50.
Reporter | ||
Updated•13 years ago
|
Comment 30•13 years ago
|
||
I noticed a similar thing on Quora (when logged in).
Reporter | ||
Comment 31•13 years ago
|
||
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
Reporter | ||
Comment 32•13 years ago
|
||
> 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•13 years ago
|
||
(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 :)
Updated•13 years ago
|
Comment 34•13 years ago
|
||
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?
Updated•13 years ago
|
Updated•13 years ago
|
Updated•13 years ago
|
Comment 35•13 years ago
|
||
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•13 years ago
|
||
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
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•13 years ago
|
||
(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?
Reporter | ||
Comment 39•13 years ago
|
||
(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.
(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•13 years ago
|
||
(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•13 years ago
|
||
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.
Updated•13 years ago
|
Comment 43•13 years ago
|
||
This is a tracking bug now, any zombie compartments found should be reported separately and block this bug.
Comment 44•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Updated•13 years ago
|
Updated•13 years ago
|
Updated•12 years ago
|
Comment 48•12 years ago
|
||
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•12 years ago
|
||
But where is the zombie in your output? Was gmail or teefury tab already closed when you looked into about:memory?
Comment 50•12 years ago
|
||
> │ ├────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•12 years ago
|
||
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•12 years ago
|
||
> 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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
:\ 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•12 years ago
|
||
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.
Reporter | ||
Comment 57•12 years ago
|
||
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•12 years ago
|
||
Looks like i won't have to, apparently Luke is already working on it in 690229
Comment 59•12 years ago
|
||
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•12 years ago
|
||
> 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.
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
We have won a great victory over the zombie army. Rejoice!
Assignee | ||
Updated•8 years ago
|
Comment 62•4 years ago
|
||
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(https://ggnewbie.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 63•4 years ago
|
||
How is it an about:blank page is using more memory than the majority of other fully featured pages?
Because the site stuck a bunch of stuff into its DOM, presumably. Just because the URL is about:blank tells you nothing about what elements are in there.
Comment 64•4 years ago
|
||
The "[26]" annotation indicates that there are 26 occurrences of all those measurements. So there are 26 about:blank compartments, and their measurements get merged in about:memory.
Also, this bug is old and closed. If you are experiencing a problem please file a new bug.
Description
•