Closed
Bug 639515
Opened 14 years ago
Closed 14 years ago
Greasemonkey 0.9.1 causes memory leak on entering/exiting private browsing mode
Categories
(Core :: General, defect)
Core
General
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: pxbugz, Unassigned)
References
()
Details
(Keywords: memory-leak, regression, Whiteboard: [addons-testday][4rc][MemShrink:P3])
Attachments
(1 file)
54.96 KB,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•14 years ago
|
||
CAUTION: clicking the endurance report in the first comment may crash firefox!
A better link is forthcoming
Comment 2•14 years ago
|
||
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.
Updated•14 years ago
|
Whiteboard: [addons-testday]
Reporter | ||
Comment 3•14 years ago
|
||
Here is a shorter 100 iteration run that should load ok
http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d0011f14
Reporter | ||
Comment 4•14 years ago
|
||
Greasemonkey beta released today showing the same issue:
http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d0013bf4
Reporter | ||
Comment 5•14 years ago
|
||
Attempt at getting a leak gauge log with greasemonkey installed causes an unusable log to be generated.
Comment 6•14 years ago
|
||
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.
Comment 7•14 years ago
|
||
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.
Keywords: regression,
regressionwindow-wanted
Comment 8•14 years ago
|
||
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]
Comment 9•14 years ago
|
||
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.
![]() |
||
Comment 11•14 years ago
|
||
Greasemonkey doesn't seem to observe the private browsing notifications, in case that matters.
Comment 12•14 years ago
|
||
(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.
Comment 13•14 years ago
|
||
> 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?
![]() |
||
Comment 14•14 years ago
|
||
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. ;)
![]() |
||
Updated•14 years ago
|
Blocks: mlk-fx4-beta
![]() |
||
Updated•14 years ago
|
Whiteboard: [addons-testday][4rc] → [addons-testday][4rc][MemShrink:P3]
Reporter | ||
Comment 15•14 years ago
|
||
No longer seeing this issue in latest nightlies with Gresemonkey 0.9.14
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Comment 16•14 years ago
|
||
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?
Reporter | ||
Comment 17•14 years ago
|
||
(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.
Updated•10 years ago
|
Keywords: regressionwindow-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•