Bug 668871 (ZombieCompartments)

[meta] Zombie Compartments! They stay alive after their tab has closed

RESOLVED FIXED

Status

Core Graveyard
Tracking
RESOLVED FIXED
6 years ago
9 months ago

People

(Reporter: Justin Lebar (not reading bugmail), Unassigned)

Tracking

(Depends on: 5 bugs, {meta, mlk})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [see comment 43 and 60], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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

6 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

6 years ago
Blocks: 668809
Whiteboard: [MemShrink]
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

6 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...
On OSX, I had a bunch of tbpl tabs opened.  When I closed them, they disappeared from about:memory.
(Reporter)

Comment 5

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

6 years ago
Thanks.  Usage is

  $ perl analyze.pl <(perl process.pl cc-edges-1.log) 0xdeadbeef
(Reporter)

Comment 8

6 years ago
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?
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. ;)
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

6 years ago
Just reproduced the leak, at least as far as about:memory is concerned, from safe mode.
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

6 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.
I was hoping per-compartment reporters would help with exactly this kind of thing! :)

jlebar, can you attach the output of about:memory?
Blocks: 659860
What do you mean by uh oh?

Could you post your steps to reproduce, so other people can try it?
(Reporter)

Comment 16

6 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

6 years ago
Created attachment 543507 [details]
Processed trace (from debug build)
Attachment #543490 - Attachment is obsolete: true
I can reproduce this on OSX 64.
This doesn't happen with cnn.com
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
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.
"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.
(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.
Summary: about:memory reports that compartments from tabs I closed still take up space → about:memory reports that compartments from TBPL tabs I closed are still present
(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?
> Did he see the TBPL compartment in about:memory?

My build doesn't have that change yet.
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.
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.
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?
It looked like it refreshed after about 2:50.
(Reporter)

Updated

6 years ago
Summary: about:memory reports that compartments from TBPL tabs I closed are still present → about:memory reports that compartments from tabs I closed are still present
I noticed a similar thing on Quora (when logged in).
(Reporter)

Comment 31

6 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

6 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.
(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

6 years ago
Whiteboard: [MemShrink] → [MemShrink:P1][meta]
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?
Alias: ZombieCompartments
Summary: about:memory reports that compartments from tabs I closed are still present → [meta] Some compartments stay alive after their page is closed
Keywords: meta, mlk
Whiteboard: [MemShrink:P1][meta] → [MemShrink:P1]
Depends on: 669545
(Reporter)

Updated

6 years ago
Depends on: 669730
Depends on: 669845

Updated

6 years ago
Depends on: 670569
Depends on: 671053
Depends on: 671114
Summary: [meta] Some compartments stay alive after their page is closed → [meta] Zombie Compartments: they stay alive after their tab has been closed
Summary: [meta] Zombie Compartments: they stay alive after their tab has been closed → [meta] Zombie Compartments! They stay alive after their tab has closed

Updated

6 years ago
Depends on: 672111
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/
(Reporter)

Updated

6 years ago
Depends on: 672619
Depends on: 672742
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.
(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

6 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.
(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.
Depends on: 673248
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.
Depends on: 673304
Depends on: 674535
This is a tracking bug now, any zombie compartments found should be reported separately and block this bug.
Whiteboard: [MemShrink:P1] → [MemShrink:P1][see comment 42 and 43]

Updated

6 years ago
Depends on: 677212

Updated

6 years ago
Depends on: 679675
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.
Whiteboard: [MemShrink:P1][see comment 42 and 43] → [MemShrink][see comment 42 and 43]

Comment 45

6 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

6 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.
Duplicate of this bug: 646666
Whiteboard: [MemShrink][see comment 42 and 43] → [MemShrink:P2][see comment 42 and 43]
Depends on: 685758
(Reporter)

Updated

6 years ago
Depends on: 688815
(Reporter)

Updated

6 years ago
Depends on: 688894

Updated

6 years ago
No longer depends on: 688815
Depends on: 691102

Updated

6 years ago
Depends on: 691537

Updated

6 years ago
Depends on: 694689
Depends on: 695348

Updated

6 years ago
Depends on: 696213

Updated

6 years ago
Depends on: 698018
Depends on: 700830
(Reporter)

Updated

6 years ago
Depends on: 701477

Updated

6 years ago
Depends on: 707403

Updated

6 years ago
Depends on: 707507

Updated

6 years ago
Depends on: 707524

Updated

6 years ago
Depends on: 707879

Updated

6 years ago
Depends on: 707964

Updated

6 years ago
Depends on: 708071
(Reporter)

Updated

6 years ago
Depends on: 708260
Depends on: 708591

Updated

5 years ago
Assignee: general → nobody
Component: JavaScript Engine → Tracking
OS: Linux → All
QA Contact: general → chofmann
Hardware: x86_64 → All

Updated

5 years ago
Depends on: 658738

Updated

5 years ago
Depends on: 711391

Updated

5 years ago
Depends on: 711675

Updated

5 years ago
Depends on: 711778

Updated

5 years ago
Depends on: 712733

Comment 48

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

Updated

5 years ago
Depends on: 714509

Comment 49

5 years ago
But where is the zombie in your output?
Was gmail or teefury tab already closed when you looked into about:memory?
> │  ├────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?

Updated

5 years ago
Depends on: 715474

Comment 51

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

5 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

5 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

5 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

5 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

5 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

5 years ago
Looks like i won't have to, apparently Luke is already working on it in 690229
No longer depends on: 673248
I'm removing the MemShrink tag, no point having it on a bug when all the blocking bugs also have the MemShrink tag.
Whiteboard: [MemShrink:P2][see comment 42 and 43] → [see comment 42 and 43]
> 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.
Whiteboard: [see comment 42 and 43] → [see comment 43 and 60]
Depends on: 717549

Updated

5 years ago
Depends on: 718127
Depends on: 718168
No longer depends on: 718127

Updated

5 years ago
Depends on: 718273
Depends on: 718375
Depends on: 705705

Updated

5 years ago
Depends on: 719782
Depends on: 720591

Updated

5 years ago
Depends on: 721319
Depends on: 723843
Depends on: 724273
Depends on: 724361
Depends on: 724377

Updated

5 years ago
Depends on: 724404

Updated

5 years ago
Depends on: 724433
Depends on: 725223
Depends on: 725603

Updated

5 years ago
Depends on: 725875
Depends on: 725956

Updated

5 years ago
Depends on: 727552

Updated

5 years ago
Depends on: 727739
Depends on: 727953
(Reporter)

Updated

5 years ago
Depends on: 727974

Updated

5 years ago
Blocks: 728008
No longer blocks: 728008
Depends on: 728008

Updated

5 years ago
Depends on: 728034
Depends on: 727938

Updated

5 years ago
Depends on: 728525

Updated

5 years ago
Depends on: 728528
Blocks: 728589
No longer blocks: 728589
Depends on: 728589

Updated

5 years ago
Depends on: 729378

Updated

5 years ago
Depends on: 729423
Depends on: 729608

Updated

5 years ago
Depends on: 729761

Updated

5 years ago
Depends on: 729948

Updated

5 years ago
Depends on: 730566

Updated

5 years ago
Depends on: 730682

Updated

5 years ago
Depends on: 730683

Updated

5 years ago
Depends on: 730784

Updated

5 years ago
Depends on: 730796
Depends on: 730846

Updated

5 years ago
Depends on: 731100
Depends on: 731105

Updated

5 years ago
Depends on: 731506
Depends on: 731801
Depends on: 731934
Depends on: 732335

Updated

5 years ago
Blocks: 732782

Updated

5 years ago
No longer blocks: 732782
Depends on: 732782
Depends on: 734097
Depends on: 734408
Depends on: 735007

Updated

5 years ago
Depends on: 735401

Updated

5 years ago
Depends on: 735766

Updated

5 years ago
Depends on: 736186
Depends on: 737972

Updated

5 years ago
Depends on: 740085
Depends on: 740363

Updated

5 years ago
Depends on: 730546

Updated

5 years ago
Depends on: 741778

Updated

5 years ago
Depends on: 742232
Depends on: 742578

Updated

5 years ago
Depends on: 742663

Updated

5 years ago
Depends on: 743215
Depends on: 743178
Blocks: 743318
No longer blocks: 743318
Depends on: 743318

Updated

5 years ago
Depends on: 745149
Depends on: 747466
Depends on: 748296
(Reporter)

Updated

5 years ago
Depends on: 752497
(Reporter)

Updated

5 years ago
Depends on: 752500
(Reporter)

Updated

5 years ago
Depends on: 752468
Depends on: 752904
Depends on: 754864
Depends on: 758298

Updated

5 years ago
Depends on: 758894

Updated

5 years ago
Depends on: 766875

Updated

5 years ago
Depends on: 768166

Updated

5 years ago
Depends on: 771577

Updated

5 years ago
Depends on: 778318

Updated

5 years ago
Depends on: 781482
Depends on: 743414
Depends on: 764840

Updated

5 years ago
Depends on: 788015
Depends on: 795221

Updated

5 years ago
Depends on: 795633

Updated

5 years ago
Depends on: 810344
Depends on: 811128

Updated

4 years ago
Depends on: 818931

Updated

4 years ago
Depends on: 835010

Updated

4 years ago
Depends on: 835011

Updated

4 years ago
Depends on: 852832
Depends on: 853046

Updated

4 years ago
Depends on: 872526
We have won a great victory over the zombie army.  Rejoice!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

2 years ago
Depends on: 1174950

Updated

a year ago
Depends on: 1255998

Updated

a year ago
Depends on: 1260372

Updated

a year ago
No longer depends on: 1260372
(Assignee)

Updated

9 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.