Closed Bug 639515 Opened 13 years ago Closed 12 years ago

Greasemonkey 0.9.1 causes memory leak on entering/exiting private browsing mode

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pxbugz, Unassigned)

References

()

Details

(Keywords: memory-leak, regression, Whiteboard: [addons-testday][4rc][MemShrink:P3])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.127 Safari/534.16
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre

Using the mozmill endurance test ( http://etherpad.mozilla.com:9000/testday-110304-addons for instructions and downloads) greasemonkey 0.9.1 shows a large increase in memory, that is never released, during the private browsing portion of the test.

Reproducible: Always

Steps to Reproduce:
1. install mozmill test suite linked above
2. run test_endurance with greasemonkey as an addon
3. check dashboard
Actual Results:  
Dashboard run http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d000e51b

Expected Results:  
Memory should be released after entering and exiting private browsing mode with the addon installed.
CAUTION: clicking the endurance report in the first comment may crash firefox!

A better link is forthcoming
Confirmed based on our results. 

(In reply to comment #0)
> http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d000e51b

Please don't click on that link unless you don't want to see your main Firefox instance be frozen. Use another instance/profile for it.

Next step would be to get some manual steps or an easy way to reproduce with the Mozmill IDE.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mlk
Version: unspecified → Trunk
Whiteboard: [addons-testday]
Here is a shorter 100 iteration run that should load ok

http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d0011f14
Greasemonkey beta released today showing the same issue:

http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d0013bf4
Attempt at getting a leak gauge log with greasemonkey installed causes an unusable log to be generated.
I can reproduce it with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110310 Firefox/4.0b13pre ID:20110310030427

Steps:
1. Install GreaseMonkey
2. Enter Private Browsing mode
3. Leave Private Browsing mode
4. Repeat steps 2-3.

As you can see the memory consumption is raising constantly and memory never gets freed again.
OS: Windows 7 → All
Hardware: x86 → All
It's less noticeable in Firefox 3.6. It's memory consumption also increases but keeps staying at 100MB on my box, while for 4.0 there is no upper limit yet.
Looks like this has been regressed between Firefox 4 beta 12 and RC 1. I will do checks with nightly builds now to narrow down the range.
Whiteboard: [addons-testday] → [addons-testday][4rc]
Not sure if I'm doing that right, but the results from leak gauge don't show any leak:

Results of processing log leak.log :

Summary:
Leaked 0 out of 0 DOM Windows
Leaked 0 out of 865 documents
Leaked 0 out of 775 docshells
Leaked content nodes in 0 out of 877 documents

David, is there another good way to get more information about?
Something else is then perhaps leaking. Some JS objects? Images in the cache? Elements?

Btw, has anyone checked whether we leak something on shutdown?

I could try to check that later today.
Greasemonkey doesn't seem to observe the private browsing notifications, in case that matters.
(In reply to comment #11)
> Greasemonkey doesn't seem to observe the private browsing notifications, in
> case that matters.

Lets add some GreaseMonkey developers to get them involved.
> Greasemonkey doesn't seem to observe the private browsing notifications, in
> case that matters.

That is correct.  But what might we do with them if we were?
Nothing I can think of offhand.  The point was that this is not a leak due to your code doing something weird in response to the notifications, since your code doesn't observe the notifications.  ;)
No longer blocks: mlk-fx5+
Whiteboard: [addons-testday][4rc] → [addons-testday][4rc][MemShrink:P3]
No longer seeing this issue in latest nightlies with Gresemonkey 0.9.14
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
I'm curious to know how you retested this. Do you have some reports that show the memory usage does not increase during the private browsing test?
(In reply to Dave Hunt (:davehunt) from comment #16)
> I'm curious to know how you retested this. Do you have some reports that
> show the memory usage does not increase during the private browsing test?

I only did this test by observing about:memory as I had tried test_endurance but it seems to get stuck on testAddons_OpenAndCloseExtensionList\test1.js with the current nightly and didn't feel up to digging around to disable the test.

There appears to be no increase in memory usage or zombie compartments so I thought to close it as there have been a few new versions of greasemonkey anyway.

If there's a way to disable that test or just run the private browsing one I can check properly and set to block Bug 700547 if necessary.
You need to log in before you can comment on or make changes to this bug.