User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre Build Identifier: It seems that Firefox is still leaking if the extensions Adblock Plus and NoScript are used together. Disable either one of them and no leak will occur. NoScript began leaking by itself within this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a6de1e28d4b&tochange=c93381b53df3 and stopped leaking after this changeset: http://hg.mozilla.org/mozilla-central/rev/9763667dfc4a Adblock Plus began leaking and got the leak fixed within that range. NoScript: https://addons.mozilla.org/en-US/firefox/addon/noscript/ Adblock Plus: https://addons.mozilla.org/addon/adblock-plus/ Reproducible: Always Steps to Reproduce: 1. Goto http://www.askmen.com/specials/top_99_women/ (slightly NSFW) 2. Allow Scripts from askmen.com to run 3. Click on "Start with No.99" 4. Click next till you get to number 80 5. Wait a few seconds to allow GC to run, and note the memory usage 6. Go back to link provided in step 1 *OR* continue clicking next Actual Results: Memory will continue to increase throughout the test, adding some 400 MB after first run. Expected Results: Memory usage should stabilize after viewing a couple of pages as it does with either of the extensions disabled. See bug 631494 and bug 634855 for more information about the leaks for the individual extensions.
Summary: Using Adblock Plus and NoScript together causing memory leak. → Using Adblock Plus and NoScript together causing memory leak
Most like a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=634855 and/or https://bugzilla.mozilla.org/show_bug.cgi?id=631494, both of which are fixed. Looks like we're waiting on a TM->MC merge to get the NoScript fix in the nightly trunk builds.
Not a dupe. No leak will occur if extensions are used individually. It is only when using both at the same time when the leak occurs.
Mozmill endurance testrun of noscript showing avg mem use of 109MB: http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d000bcc8 Adblock avg 106MB: http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d000b10f Noscript + Adblock avg 112MB: http://mozmill.blargon7.com/#/endurance/report/66e0fb6bd5645ddae0ee8e21d000d121 Please note that mozmill runs these addons without any filters loaded or specified so that may account for why these tests appear to show no memory increase with both addons loaded. In that case it may be likely that a filter is still triggering a memory leak, as in Bug 631494 Instructions to run the mozmill tests are here: http://etherpad.mozilla.com:9000/testday-110304-addons
Those mozmill endurance test does not run on the askmen.com site where this bug is most appearent. You need to run the specific test for askmen.com, as seen in these mozmill tests: http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c15010493 http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c1500f7be
(In reply to comment #4) > Those mozmill endurance test does not run on the askmen.com site where this bug > is most appearent. You need to run the specific test for askmen.com, as seen in > these mozmill tests: > > http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c15010493 > http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c1500f7be Can you link to the filterset used for adblock, or were these tests run with no filters loaded?
(In reply to comment #5) > (In reply to comment #4) > > Those mozmill endurance test does not run on the askmen.com site where this bug > > is most appearent. You need to run the specific test for askmen.com, as seen in > > these mozmill tests: > > > > http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c15010493 > > http://mozmill.blargon7.com/#/endurance/report/aa40f05493d5cee5fc40cc7c1500f7be > > Can you link to the filterset used for adblock, or were these tests run with no > filters loaded? You can run EasyList (I believe this is the one suggested by defautlt): https://easylist-downloads.adblockplus.org/easylist.txt When running NoScript, scripts from askmen.com must be allowed, otherwise the bug doesn't seem to appear. May as well add Facebook and Twitter servers to the allowed list as they both add some DOM-elements to every page.
In this case I have managed to get to minimal filter/script combination where ram usage increases and then at least 100MB is never released after leaving the askmen site. Adblockplus needs only these 2 filters enabled: |http://wrapper.*/a? ||disqus.com/stats.html Noscript needs to allow only: askmen.com disqus.com
No longer blocks: 467520
I'll find someone in QA to try to reproduce and verify as well.
Is NoScript a requirement of this bug? This seems extremely similar (if not a dupe) of bug 638068.
For askmen.com it is. Following the instructions in the description memory usage topped out at about 390 MB with only one of the extensions enabled, when using both, the memory usage went up continuously at a rate of about 200 MB / 20 pages.
Do you think this bug of mine is related? bug 642472
Also on firefox 4 x86-x64. Even just using firefox throughout the day causes this memory leak. Adblock+ and Noscript.
No longer blocks: 632234
No longer blocks: 640452
Tried this again with the latest nightly of Firefox and the latest dev version of both extensions and I'm still seeing this bug. Memory usage during test: Explicit Allocations 690.41 MB (100.0%) -- explicit ├──343.14 MB (49.70%) -- heap-unclassified ├──279.52 MB (40.49%) -- js │ ├──205.00 MB (29.69%) -- gc-heap │ ├───40.09 MB (05.81%) -- mjit-code │ ├───30.99 MB (04.49%) -- tjit-data │ │ ├──23.99 MB (03.48%) -- allocators-reserve │ │ └───7.00 MB (01.01%) -- allocators-main │ └────3.45 MB (00.50%) -- (2 omitted) ├───31.03 MB (04.49%) -- images │ ├──30.78 MB (04.46%) -- content │ │ ├──30.78 MB (04.46%) -- used │ │ │ ├──27.06 MB (03.92%) -- uncompressed │ │ │ └───3.72 MB (00.54%) -- raw │ │ └───0.00 MB (00.00%) -- (1 omitted) │ └───0.26 MB (00.04%) -- (1 omitted) ├───27.42 MB (03.97%) -- gfx │ └──27.42 MB (03.97%) -- surface │ └──27.42 MB (03.97%) -- image ├────7.67 MB (01.11%) -- storage │ └──7.67 MB (01.11%) -- sqlite │ └──7.67 MB (01.11%) -- (14 omitted) └────1.62 MB (00.24%) -- (1 omitted) Other Measurements 2,060.09 MB -- vsize 941.52 MB -- resident 673.66 MB -- heap-zone0-used 444.83 MB -- heap-zone0-committed 444.83 MB -- heap-used 231.83 MB -- heap-unused After: Explicit Allocations 265.37 MB (100.0%) -- explicit ├──188.99 MB (71.22%) -- js │ ├──181.00 MB (68.21%) -- gc-heap │ ├────5.52 MB (02.08%) -- mjit-code │ └────2.47 MB (00.93%) -- (3 omitted) ├───66.81 MB (25.18%) -- heap-unclassified ├────8.00 MB (03.02%) -- storage │ └──8.00 MB (03.02%) -- sqlite │ ├──2.69 MB (01.01%) -- urlclassifier3.sqlite │ │ ├──2.60 MB (00.98%) -- cache-used │ │ └──0.08 MB (00.03%) -- (2 omitted) │ ├──1.90 MB (00.72%) -- places.sqlite │ │ ├──1.63 MB (00.62%) -- cache-used │ │ └──0.26 MB (00.10%) -- (2 omitted) │ └──3.42 MB (01.29%) -- (12 omitted) └────1.56 MB (00.59%) -- (3 omitted) Other Measurements 1,847.80 MB -- vsize 782.28 MB -- resident 533.43 MB -- heap-zone0-used 458.03 MB -- heap-unused 78.41 MB -- heap-zone0-committed 78.41 MB -- heap-used
My prime suspect would be the code attaching data to HTTP channels. NoScript works similarly to Adblock Plus here, it matches channels to preceding content policy calls and attaches arguments of the call to channels (see Policy.js/RequestWatchdog.js). The cleanup approach is different however - Adblock Plus uses nsITraceableChannel for that while NoScript tracks channel completion via tabbrowser's nsIWebProgressListener (see Main.js). What could be meant by "heap-unclassified"? DOM nodes? Channels?
Wladimir: "heap-unclassified" is the "everything else" bucket for memory usage that doesn't have a specific entry. Bug 563700 is open to reduce its size.
Whiteboard: [dupeme?] → [dupeme?][MemShrink:P3]
Wladimir, does this have anything to do with bug 672111?
Given that this isn't a zombie compartment - it isn't a dup. Also, bug 672111 isn't really a memory leak, it will hold at most one compartment at a time (and that compartment can be released as soon as a different web page makes a request). But the mechanism I describe in comment 14 is indeed the redirect detection, it might have something to do with this bug as well.
Works for me on Mac OS 10.9 using Lastest Nightly 25. If someone can still reproduce this issue please reopen the bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.