Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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 Dec 7, 2011 · 6 comments
Closed

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

Fanolian opened this issue Dec 7, 2011 · 6 comments
Labels
confirmed
Milestone
0.9.14

Comments

@Fanolian
Copy link

Fanolian commented Dec 7, 2011

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
Copy link
Collaborator

arantius commented Jan 8, 2012

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

@Fanolian
Copy link
Author

Fanolian commented Jan 8, 2012

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
Copy link
Collaborator

arantius commented Jan 8, 2012

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
Copy link
Collaborator

arantius commented Jan 8, 2012

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
Copy link
Collaborator

arantius commented Jan 9, 2012

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 added a commit to arantius/greasemonkey that referenced this issue Jan 9, 2012
@arantius
Fix logic bug.
35feeb0 
Refs greasemonkey#1482
@arantius
Copy link
Collaborator

arantius commented Jan 9, 2012

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
Assignees
No one assigned
Labels
confirmed
Projects
None yet
Milestone
0.9.14
Development

No branches or pull requests
2 participants
@arantius @Fanolian