Skip to content
This repository

GM_registerMenuCommand may cause zombie compartments if a tab containing scripts with this function is opened in the background #1482

Closed
Fanolian opened this Issue · 6 comments

2 participants

Fanolian arantius
Fanolian

More info can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=707403.
However, the user script mentioned in comment#0 has updated so you need to use another test case.

Steps to reproduce:
1. Install the latest Greasemonkey.
2. Enable a script that contains GM_registerMenuCommand.
3. Open a tab in background which would trigger the said script.
4. Close the tab, Open about:memory?verbose.
5. Minimize memory usage and check for the zombie compartment.

It should be noted that opening a tab in foreground does not create a zombie compartment.

arantius
Collaborator

So far, I created https://gist.github.com/1576836 but I never see the word zombie in the about memory page.

Fanolian

I am sorry that I describe the bug wrongly at the first place. A tab with a script triggering (not only containing) GM_registerMenuCommand opened in the background results in a zombie compartment.

I can still produce zombie compartments using your test script in Firefox 9.0.1 and latest Nightly (2012-01-07). You do not see the word "zombie" in about:memory?verbose as it is only a concept. From https://developer.mozilla.org/en/Zombie_Compartments :

Zombie compartments

Sometimes, due to bugs in Firefox and/or add-ons, compartments are created that are never destroyed. These are a particular kind of memory leak, and they cause Firefox's memory usage to increase gradually over time, slowing it down and making it more likely to crash.

Here are my steps to produce a zombie compartment from your script:

  1. Create a simple test page (since your script triggers GM_registerMenuCommand on about:blank only).
    <html><body>
    <a href="about:blank">about:blank</a>
    </body></html>

  2. Install Greasemonkey 0.9.13 and your test script in a new profile.

  3. Open about:memory?verbose in a tab. Make sure there is no compartment(about:blank) left at this moment.
  4. Open the test page in another tab. Middle click the link in the page so about:blank is opened in a background new tab. (This is important since a zombie compartment by Greasemonkey is created from a background tab only.)
  5. Close the blank page and the test page, wait for a minute and then check about:memory?verbose again.

Now a compartment(about:blank) should stay even if the blank tab is closed for a while. Clicking GC/CC/Minimize_memory_usage does not destroy this compartment. The compartment should look like this:
│ ├─────148,192 B (00.43%) -- compartment(about:blank)
│ │ ├──135,168 B (00.39%) -- gc-heap
│ │ │ ├───95,864 B (00.28%) -- arena-unused [2]
│ │ │ ├───22,392 B (00.07%) -- objects [2]
│ │ │ ├───13,840 B (00.04%) -- shapes [2]
│ │ │ ├────1,504 B (00.00%) -- type-objects [2]
│ │ │ ├──────560 B (00.00%) -- arena-padding [2]
│ │ │ ├──────528 B (00.00%) -- arena-headers [2]
│ │ │ └──────480 B (00.00%) -- scripts [2]
│ │ ├────8,576 B (00.03%) -- object-slots [2]
│ │ ├────1,504 B (00.00%) -- type-inference
│ │ │ └──1,504 B (00.00%) -- object-main [2]
│ │ ├────1,408 B (00.00%) -- property-tables [2]
│ │ ├──────800 B (00.00%) -- shape-kids [2]
│ │ ├──────672 B (00.00%) -- object-empty-shapes [2]
│ │ ├───────32 B (00.00%) -- script-data [2]
│ │ └───────32 B (00.00%) -- analysis-temporary [2]

I am sorry again that I misguided you at first.

arantius
Collaborator

I read one of the comments at bugzilla wrong; it wasn't immediately clear what part was the typed comment and what was the copy/pasted data.

Anyway: with a tweak to the test script to make it more obvious (now that I know what to look for), confirmed.

This is on Windows XP and Firefox Mozilla/5.0 (Windows NT 6.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1. (I need to update that ...)

arantius
Collaborator

I read one of the comments at bugzilla wrong; it wasn't immediately clear what part was the typed comment and what was the copy/pasted data.

Anyway: with a tweak to the test script to make it more obvious (now that I know what to look for), confirmed.

This is on Windows XP and Firefox Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1.

arantius arantius closed this in 40993dd
arantius
Collaborator

This should fix things. Please check the next nightly (after 2012.01.08, should be up in a few hours) available at:

https://arantius.com/misc/gm-nightly/

To confirm.

arantius arantius referenced this issue from a commit in arantius/greasemonkey
arantius Fix logic bug.
Refs #1482
35feeb0
arantius
Collaborator

Fix confirmed upstream at the linked bugzilla bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.