Bug - memory grows indefinitely

Everything about using Adblock Plus on Google Chrome
Post Reply
Josa
Posts: 2
Joined: Tue Oct 27, 2015 2:32 pm

Bug - memory grows indefinitely

Post by Josa »

To reproduce:
Load http://super.abril.com.br/blogs/oraculo ... -terminou/
Result: memory will grow indefinitely

This happens on Chrome 46.0.2490.80 with ABP 1.9.3 and Firefox Nightly with ABP 2.6.11.3992-beta. On both ABP I have: Easylist, Fanboy's Spanish/Portuguese and allow some non-intrusive advertising. If I disable ABP, the page loads just fine and doesn't cause any problems. I'm on Windows 7.
These are the versions I tested, but I saw this happening months ago on Nightly but just didn't fill a bug.
Because it happens on two different browsers I didn't post it on their subforums, but here.
User avatar
mapx
Posts: 21940
Joined: Thu Jan 06, 2011 2:01 pm

Re: Bug - memory grows indefinitely

Post by mapx »

I can't reproduce the issue in chrome 47.
Did you try keeping only easylist enabled ? Does still happen ?
A test only with ABP enabled and the other extensions turned OFF ?

If you open task manager in chrome where is growing the memory: on the extension or on the page ?

probably that fanboy list is outdated, did you try that 1:
Filtros Nauscopicos
español

from
en/subscriptions
Josa
Posts: 2
Joined: Tue Oct 27, 2015 2:32 pm

Re: Bug - memory grows indefinitely

Post by Josa »

So, it happens with Easylist enabled AND "allow some non-intrusive advertising". If this option is not enabled, no problem.
The memory growth (and cpu usage, I forgot to say), happens on the page process.

I use that Fanboy list because I live in Brazil (so it's the Portuguese part that is important for me). It's outdated but it still blocks alot of things of brazilian websites.
User avatar
mapx
Posts: 21940
Joined: Thu Jan 06, 2011 2:01 pm

Re: Bug - memory grows indefinitely

Post by mapx »

Finally I reproduced the issue

If I disable these 2 filters ==> memory / CPU are ok

Code: Select all

@@||googleadservices.com^$third-party
@@||google.com/adsense/search/*.js$domain=~nextag.com|~calibex.com|~nextag.ca|~wize.com|~applianceshopping.com|~pricemachine.com|~luckypetstore.com|~healthlane.com|~sportslane.com|~toyshub.com|~homegardenpro.com|~nextag.co.uk|~nextag.de|~nextag.es|~nextag.fr|~nextag.it|~nextag.nl|~omniprix.com|~calibex.co.uk|~guenstiger.de|~preissuchmaschine.de|~pricemachine.co.uk|~pricemachine.fr|~nextag.com.au|~nextag.co.jp|~calibex.com.au|~calibex.jp|~iinedan.com|~modelane.com|~target.com|~kieskeurig.nl|~juno.com|~startpagina.nl|~netzero.net|~mybluelight.com|~kieskeurig.be|~overzicht.nl|~mysite.com|~huuto.net|~netzero.com|~nusport.nl|~vrouwonline.nl|~grazia.nl|~untd.com|~koopje24.nl
User avatar
greiner
ABP Developer
Posts: 899
Joined: Mon Sep 03, 2012 5:29 pm
Location: Cologne, Germany

Re: Bug - memory grows indefinitely

Post by greiner »

This issue occurs due to bad error handling inside http://super.abril.com.br/libc/ads/abrad_criteo.js

It checks every second whether the "GPT implementation script" is loaded and since that one was blocked by Adblock Plus, this leads to an infinite loop (= CPU usage). In addition to that the implementation has a memory leak problem which means that the memory just keeps on growing indefinitely.

Basically, all they need to do is add a listener that's executed when the script is loaded (see https://developers.google.com/doublecli ... -listeners) or at least (a) stop checking after the request failed or (b) add a maximum time after which this check is aborted.
User avatar
mapx
Posts: 21940
Joined: Thu Jan 06, 2011 2:01 pm

Re: Bug - memory grows indefinitely

Post by mapx »

yeah, but why removing 2 exception filters the site will work ? Usually if something is blocked could cause an infinite loop. Here's completely upside down.
User avatar
greiner
ABP Developer
Posts: 899
Joined: Mon Sep 03, 2012 5:29 pm
Location: Cologne, Germany

Re: Bug - memory grows indefinitely

Post by greiner »

That'd take more time to find out since the code is minified so all I can say at this point is that this specific part of the code is producing this odd behavior. I can image that they may have proper error handling for the scripts that are whitelisted but not for anything that follows and thereby causing this issue only if the mentioned scripts are whitelisted.

Anyway, I'm confident that by following best practices this issue can be resolved on their end.
Post Reply