668871 - (ZombieCompartments) [meta] Zombie Compartments! They stay alive after their tab has closed

Status: RESOLVED FIXED

(Core Graveyard :: Tracking, defect)

Description

[Justin Lebar (not reading bugmail)]

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)]

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 (out of office until 8/21) [:mccr8]]

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)]

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 (out of office until 8/21) [:mccr8]]

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)]

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 (out of office until 8/21) [:mccr8]]

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)]

Thanks.  Usage is

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

Comment 8

[Justin Lebar (not reading bugmail)]

Attachment: 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 (out of office until 8/21) [:mccr8]]

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 (out of office until 8/21) [:mccr8]]

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)]

Just reproduced the leak, at least as far as about:memory is concerned, from safe mode.

Comment 12

[Andrew McCreight (out of office until 8/21) [:mccr8]]

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)]

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 [inactive]]

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 (out of office until 8/21) [:mccr8]]

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)]

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)]

Attachment: Processed trace (from debug build)

Comment 18

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I can reproduce this on OSX 64.

Comment 19

[Andrew McCreight (out of office until 8/21) [:mccr8]]

This doesn't happen with cnn.com

Comment 20

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Attachment: 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 (out of office until 8/21) [:mccr8]]

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 (out of office until 8/21) [:mccr8]]

"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 [inactive]]

(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 [inactive]]

(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 [:bzbarsky]]

> Did he see the TBPL compartment in about:memory?

My build doesn't have that change yet.

Comment 26

[Andrew McCreight (out of office until 8/21) [:mccr8]]

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 (out of office until 8/21) [:mccr8]]

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 (out of office until 8/21) [:mccr8]]

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 (out of office until 8/21) [:mccr8]]

It looked like it refreshed after about 2:50.

Comment 30

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I noticed a similar thing on Quora (when logged in).

Comment 31

[Justin Lebar (not reading bugmail)]

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)]

> 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 [inactive]]

(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 [inactive]]

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 (out of office until 8/21) [:mccr8]]

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]]

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 (Exited; not receiving bugmail, old account, do not use)]

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]]

(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)]

(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 (Exited; not receiving bugmail, old account, do not use)]

(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]]

(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 [inactive]]

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 [inactive]]

This is a tracking bug now, any zombie compartments found should be reported separately and block this bug.

Comment 44

[Nicholas Nethercote [inactive]]

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]

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]

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 48

[Aq]

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]

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 [inactive]]

> │  ├────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]

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 [inactive]]

> 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]

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]

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]

:\ 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]

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)]

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]

Looks like i won't have to, apparently Luke is already working on it in 690229

Comment 59

[Nicholas Nethercote [inactive]]

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 [inactive]]

> 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 (Exited; not receiving bugmail, old account, do not use)]

We have won a great victory over the zombie army.  Rejoice!

Comment 62

[sinektiz]

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

[Boris Zbarsky [:bzbarsky]]

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

[Nicholas Nethercote [inactive]]

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.