Closed Bug 639186 Opened 13 years ago Closed 11 years ago

Using Adblock Plus and NoScript together causing memory leak

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: danne.da, Unassigned)

References

(
URL
)

Details

(Keywords: memory-leak, Whiteboard: [dupeme?][MemShrink:P3]) 

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
Version: unspecified → Trunk
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.
Blocks: mlk2.0
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
Blocks: abp
No longer blocks: abp
I'll find someone in QA to try to reproduce and verify as well.
Keywords: qawanted
Is NoScript a requirement of this bug? This seems extremely similar (if not a dupe) of bug 638068.
Whiteboard: [dupeme?]
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: mlk2.0
No longer blocks: mlk-fx5+
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]
Keywords: mlk
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
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.