Memory leak in firefox 3.6+

[Cloud]

Anoniem: 303530 schreef op vrijdag 25 maart 2011 @ 21:33:
[...]

Niet vergeten de regkey "close window whit last tab" (even zoeken) op false te zetten.

Ah vandaar dat ik laatst je script niet werkend kreeg, mijn Firefox sloot de hele tijd af Zal binnenkort als ik wat langer de tijd heb weer een test doen. Dan overigens wel met Firefox 4. Maar gezien het geheugengebruik (650 MB) wat ik vandaag op m'n werkstation voorbij zag komen met maar 2 tabs open, is het toch nog lang niet in opgelost.

[Max Hunt]

Ik ben nog niet zo bedreven bezig geweest met het testen van Firefox's geheugen lek, mijn manier is denk ik wat sneller en groffer. Ik gebruik op dit moment 4.0 maar in ieder geval sinds 3.6.xx heb ik last gehad van enorm veel geheugen gebruik in Firefox.

Ik test het door gewoonweg een hele berg tabs te openen en dan weer te sluiten. Zelfs in veilige modus van Firefox kan ik op die manier met een paar minuten 6-700mb geheugen gebruik hebben met uiteindelijk maar 1 tab open.

Naar mijn gevoel loopt het geheugen met 4.0 wel wat sneller vol. Met 3.6 hoefde ik Firefox maar 1 keer af te sluiten per 2-3 dagen, soms iets sneller. Vandaag liep mijn geheugen al vol binnen een halve dag. Ik had wel wat meer websites bezocht, maar ik was ook nog bezig met userChrome instellingen waardoor ik vanochtend nog veelvoudig firefox opnieuw had opgestart.

[AMD1800]

Anoniem: 303530 schreef op zaterdag 19 maart 2011 @ 15:29:
[knip]

Edit: het zou fijn zijn als firefox 1 proces per tabblad aanmaakt, daarmee gaat het testen van dit soort dingen flink sneller.

Laat ze dan maar met subprocessen gaan werken, want ik hoef geen 10000 processen van 1 programma in mn taakbeheer. Dan raakt het overzicht ook een keer zoek natuurlijk.

[Anoniem: 303530]

Ik heb het idee dat het erger is geworden sinds firefox 4, zijn er hier mensen die die mening delen?

Hij staat hier pas een halve dag aan en is nu al traag als stront, gelukkig heb ik die handige restart plugin gedownload...

In mij VM ben ik er nog niet achter gekomen wat de oorzaak is, ik zal kijken of er een manier bestaat om meer verschillende pagina's tegelijk te bezoeken in plaats van telkens dezelfde.

[ovigo]

Ik heb niet echt het idee dat het veel erger is geworden, maar bij mij is het ook nooit heel erg obvious geweest. Feit is wel dat het geheugengebruik nogsteeds erg fors is voor een browser... Zal er eens aan proberen m niet af te sluiten, kijken hoever t oploopt komende dagen.

[Beatboxx]

Ik ga dit nu ook eens proberen. Ik het net de meest recente versie van FF4, die reload 5 tabs elke 5 secondes. Ik post over een uurtje of twee eens de resultaten!

EDIT: Er komt nu zo'n 1MB per minuut bij... Schokkend?

[ Voor 15% gewijzigd door Beatboxx op 26-03-2011 18:02 ]

[Beatboxx]

Zojuist 40 minuten laten draaien, met 5 tabs die elke 5 secondes refreshen. Dit betreft FF 4.0. De tijd tussen twee meetpunten betrof 25 seconden. Ik zal morgen eens chrome, FF en IE tegelijk laten draaien, en het naast elkaar zetten!

[ovigo]

Op Basis van dit artikel eens mn JRE geupdate. Lijkt ietwat te helpen voor geheugengebruik, maar heb het idee dat het weer aan het stijgen is. Sowieso heeft Java 64-bit en 32-bit versies, kan me voorstellen dat dat weer raar doet aangezien FF 32-bit is, ook op 64-bit systemen?
Ter informatie in ieder geval.

[Anoniem: 303530]

Ik zal het even proberen, maar ik geloof dat ik al de laatste versie heb. Ik heb vorige weer een herinstallatie gedaan e mijn profiel overgeplaatst. Sindsdien heb ik nog geen nieuwe test gedaan.
Nu ja, een korte test waaruit bleek dat het probleem nog niet is verholpen.

[Beatboxx]

Waarom werkt dit niet:

code:

while (1)
{
start-sleep -s 60
(get-process -name chrome).workingset >> chrome.txt
}

[Anoniem: 303530]

Omdat chrome een stuk of 5 processen spawnt.

bekijk maar eens het verschil tussen:

get-process -name chrome

en

get-process -name firefox

Gelukkig heb ik daar iets op gevonden:

$a = get-process chrome
$total = 0; foreach($process in $a) { $total += $process.workingset }
$total >> file.txt

...in een while loop gooien en file.txt vervangen door een filenaam naar keuze.

Edit: handige truuk om allerlei verchillende pagina's te bezoeken met een handig script:

[void] [System.Reflection.Assembly]::LoadWithPartialName("'System.Windows.Forms")
[void] [System.Reflection.Assembly]::LoadWithPartialName("'Microsoft.VisualBasic")
& 'C:\Program Files (x86)\Mozilla Firefox\firefox.exe'
start-sleep -s 10
while (1) {
[Microsoft.VisualBasic.Interaction]::AppActivate("firefox")
[System.Windows.Forms.SendKeys]::SendWait("%dhttp://gathering.tweakers.net/forum/list_activetopics{enter}")
start-sleep -s 10

[Microsoft.VisualBasic.Interaction]::AppActivate("firefox")
[System.Windows.Forms.SendKeys]::SendWait("^fvolgende pagina{esc}{tab}{enter}")
start-sleep -s 10
}

[ Voor 47% gewijzigd door Anoniem: 303530 op 26-03-2011 19:59 ]

[Beatboxx]

Anoniem: 303530 schreef op zaterdag 26 maart 2011 @ 19:37:

Gelukkig heb ik daar iets op gevonden:

$a = get-process chrome
$total = 0; foreach($process in $a) { $total += $process.workingset }
$total >> file.txt

...in een while loop gooien en file.txt vervangen door een filenaam naar keuze.

Okay, maar in een while loop wordt het:

while (1)
{
start-sleep -s 60
$a = get-process chrome
$total = 0; foreach($process in $a) { $total += $process.workingset }
$total >> file.tx
}

EDIT: Ja, het werkt. En dat is dus alle chrome processen bij elkaar?

[ Voor 5% gewijzigd door Beatboxx op 26-03-2011 20:18 ]

[Anoniem: 303530]

yep.

[Beatboxx]

Ik had achteraf gezien niet 2 browser's 6 pagina's van Tnet moeten laten refreshen:S Nu heb ik een ip bann... FAIL. Ik heb wel hele mooie resultaten! Chrome lekt ruim 2x zoveel memory als FF:O (70MB in 30 minuten tov 30MB)

[Anoniem: 303530]

FAIL.

Ik speel het wel even door.

[Beatboxx]

Dankje, ik heb ook al een mail gestuurd naar [e-mail]. Mijn ip is 84.85.92.208. Ik ga morgen een experiment doen met nog veel meer browsers, ben benieuwd naar de uitkomst!

[Anoniem: 303530]

Overigens kan je zoveel refreshen als je wilt, maar als je refresh voordat de pagina volledig is geladen heeft het waarschijnlijk niet het gewenste effect.

[Beatboxx]

Hij was wel steeds geladen, mijn internet is snelll:) Ik ga morgen een heel uitgebreide test doen van zo'n 4 uur ofzo, met veel meer verschillende site's enzo.


EDIT: IP bann is over:)

[ Voor 8% gewijzigd door Beatboxx op 26-03-2011 22:09 ]

[Anoniem: 303530]

De java update heeft niet het gewenste effect. Na 4 uur zit ik al op 700MB, met firefox 3.6 duurde het nog 9 uur om zoveel RAM vol te krijgen.

[Anoniem: 19894]

Ik draai zelf geen Java, zit op een 313mb geheugengebruik op FF4 (geen reboot sinds de laatste meting), Vista SP2 32 bit, laptop draait inmiddels weer een dag of vijf.

[Beatboxx]

Ik ga zometeen de meest uitgebreide test doen die je je maar kan bedenken:P Dit keer ga ik gewoon even een iis webserver opzetten:P Ik ga werken met:

• Firefox
• Chrome
• Opera
• Safari
• IE 9.0

Lijkt me toch een behoorlijk uitgebreide test? Alleen, hoe kan je automatisch page's refreshen op safari?

EDIT: Met IE krijg ik het ook niet voor elkaar om automatisch te refreshen:S

[ Voor 11% gewijzigd door Beatboxx op 27-03-2011 10:55 ]

[Anoniem: 303530]

Je kan beter elke browser hetzelfde powershell script laten draaien, zoals een stukje terug:

Anoniem: 303530 in "Memory leak in firefox 3.6+".

...Wel een andere site dan tweakers nemen, en ik weet niet of het gaat werken met chrome.
Laat ik je er even op wijzen dat refreshen alleen niet echt een realistisch scenario is. Bij mij leakt er helemaal niets als ik refresh in een VM, maar als ik gewoon pagina's bezoek wel. (wat overigens na een tijdje weer geclaimd word)

[Beatboxx]

Wat is dan wel een realistische test? Ik denk gewoon zo'n 12 verschillende pagina's openen die steeds opnieuw laden... Of je moet iets maken dat random pagina's uit je history laad, nog beter

[Anoniem: 303530]

Ik laad elke 20 seconden de bovenste pagina van actieve topics hier op GoT:

oranje lijn. De rest van de lijnen zijn grotendeels ctrl+W en F5 acties.

Het is duidelijk dat je dit probleem niet hebt met een standaardinstallatie met alleen ABP, ABP conflicteert dus ergens mee, maar met wat? Dit gaat nog wel even duren...

[ Voor 6% gewijzigd door Anoniem: 303530 op 27-03-2011 17:16 ]

[curvemod]

Interessant topic, ik heb ook al een tijdje het gevoel dat FF steeds trager wordt en dit geldt zeker voor 3.6 en 4.

Op mijn werk doe ik momenteel veel met Javascript ontwikkeling, en ik moet de browser iedere 2 tot 3 uur herstarten omdat het echt onwerkbaar wordt. Dit wordt trouwens niet veroorzaakt door add-ons, gebruik alleen Firebug en FirePHP . Ik ben erg benieuwd naar de uitkomst van de tests!

[Webgnome]

jhuiting schreef op zondag 27 maart 2011 @ 17:24:
Interessant topic, ik heb ook al een tijdje het gevoel dat FF steeds trager wordt en dit geldt zeker voor 3.6 en 4.

Op mijn werk doe ik momenteel veel met Javascript ontwikkeling, en ik moet de browser iedere 2 tot 3 uur herstarten omdat het echt onwerkbaar wordt. Dit wordt trouwens niet veroorzaakt door add-ons, gebruik alleen Firebug en FirePHP . Ik ben erg benieuwd naar de uitkomst van de tests!

Dit probleem heb ik ook ondervonden als ik veel aan dojo achtige zaken bezig ben. Ik heb daar toen een verklaring voor gezocht en een mogelijke gevonden. Als je op een pagina mbh javascript listeners aan elementen hangt of onload functionaliteiten dan zul je ze ook weer moeten verwijderen omdat je er blijkbaar niet vanuit kunt gaan dat de browser dit netjes uit zijn geheugen gooit.

[ovigo]

Zie ook http://support.mozilla.com/en-US/questions/669659. Ik heb inmiddels een zooi addons uitgeschakeld en ga als ik over de 500 MB voor 7-8 tabs ga in deze sessie herstarten in save mode, kijken of ik dan nogsteeds na verloop van tijd over de 500 MB ga. (+-2 dagen voor mij momenteel)

[Anoniem: 303530]

En toen waren we -een heel stuk- verder, een 5tal grafiekjes met een willekeurige pagina bezoeken op GoT, volledig geautomatiseerd.



Wat is de overeenkomst tussen de 2 blauwe lijntjes?
En hoe wist ik de memory leak bij de lichtblauwe lijn te stoppen zonder mijn VM aan te raken?

spoiler:

Zodra ik inlog begint firefox als een gek memory te lekken, zodra ik de sessie beëindig loopt de lijn weer vlak....

insert hiet heel veel in een <marquee> element...

[Webgnome]

Anoniem: 303530 schreef op maandag 28 maart 2011 @ 00:56:

spoiler:

Zodra ik inlog begint firefox als een gek memory te lekken, zodra ik de sessie beëindig loopt de lijn weer vlak....

insert hiet heel veel in een <marquee> element...

zou het dan niet aan ff liggen maar aan de site die niet alle zooi netjes opruimt?

[Beatboxx]

Hoe laat je m random een pagina op een site bezoeken???? Ik maak trouwens nu even een hele mooie grafiek van Chrome, die komt straks als mijn proefwerken klaar zijn.

[ Voor 49% gewijzigd door Beatboxx op 28-03-2011 10:14 ]

[Cloud]

Anoniem: 303530 schreef op maandag 28 maart 2011 @ 00:56:
Wat is de overeenkomst tussen de 2 blauwe lijntjes?
En hoe wist ik de memory leak bij de lichtblauwe lijn te stoppen zonder mijn VM aan te raken?

spoiler:

Zodra ik inlog begint firefox als een gek memory te lekken, zodra ik de sessie beëindig loopt de lijn weer vlak....

insert hiet heel veel in een <marquee> element...

Dat is echt heel raar Ik heb geen idee waar we dat in moeten zoeken. Misschien iets met caching binnen de browser zelf ofzo? De kans dat het aan de site tweakers.net ligt, lijkt mij klein. Dat zou betekenen dat alleen gebruikers van T.net last van dit probleem hebben, maar gezien de online discussies is dat niet zo.

[Beatboxx]

Of het ligt gewoon aan het inloggen zelf, dat inloggen op een andere website ook leak veroorzaakt? Maar chrome leakt ook. Maken we daar een nieuw topic over of doen we dat ook hier?

EDIT: Ik laat chrome nu 8 tabs van website's die ik vaak bezoek random tussen de 10 en 60 secondes refreshen. Dat zorgt voor een behoorlijke leak, kan ik je vertellen!

[ Voor 32% gewijzigd door Beatboxx op 28-03-2011 10:25 ]

[KiPKaKDutcH]

Beatboxx schreef op maandag 28 maart 2011 @ 10:20:
Of het ligt gewoon aan het inloggen zelf, dat inloggen op een andere website ook leak veroorzaakt? Maar chrome leakt ook. Maken we daar een nieuw topic over of doen we dat ook hier?

EDIT: Ik laat chrome nu 8 tabs van website's die ik vaak bezoek random tussen de 10 en 60 secondes refreshen. Dat zorgt voor een behoorlijke leak, kan ik je vertellen!

Welke versie?

[Anoniem: 303530]

Beatboxx schreef op maandag 28 maart 2011 @ 10:09:
Hoe laat je m random een pagina op een site bezoeken???? Ik maak trouwens nu even een hele mooie grafiek van Chrome, die komt straks als mijn proefwerken klaar zijn.

Zo: Anoniem: 303530 in "Memory leak in firefox 3.6+"

Na nog wat tests is het volgende duidelijk geworden:

inloggen: geen probleem
adblock plus: geen probleem
beiden: na een uur 300MB memory geleakt.

Ik ga even bij de devvers navraag doen wat er zoal anders is als je ingelogd. Ik gok op een javascript leak ergens, of mogelijk zelfs cookies die lopen te bokken in firefox.

Laat maar zitten eigenlijk, de devvers kunnen hier natuurlijk niets aan doen. Dit -of altans, in deze specifieke situatie- gewoon een enorm gat in adblock plus.

Alternatieven voor bovenstaande addon zijn welkom...

[ Voor 14% gewijzigd door Anoniem: 303530 op 29-03-2011 01:44 ]

[Cloud]

Alternatieven heb ik nog niet echt. Ik zie hier wel een bugreport bij Mozilla die hier behoorlijk op lijkt:
https://bugzilla.mozilla.org/show_bug.cgi?id=631494. Maar deze schijnt al opgelost te zijn.

Maar sowieso, als ik bij Mozilla zoek op 'memory leak' dan krijg ik 425 open bugreports, waaronder nog een paar andere waar AdblockPlus genoemd wordt. Nu zal een deel veroorzaakt worden door de gebruiker zelf, maar dan nog zijn dat een hoop memory leaks. Zal inderdaad lastig worden om aan te wijzen waar het nu precies fout gaat..

[Swedish Clown]

Gaat hier ook na de update naar Firefox 4 nog steeds niet goed... Reeks 1 was echt extreem! Was wel flink aan het surfen in die tijd maar tikte op een gegeven moment ruim de 1 GB aan...

Reeks 2 is over een langere periode en is "gemiddeld surfen", niks geen idioot geklik of wat dan ook gewoon het standaard browsen op een niet productieve avond.

[Anoniem: 303530]

Ik ben er ook meteen achter waarom ik zoveel naar mijn SSD schrijf:..



Dit is na 3 uur en 15 minuten surfen, jammer dat dat niet allemaal in het RAM word gecachet aangezien de meeste data naar _CACHE1_ 2, en 3 word geschreven.

Edit: en naar bepaalde SQlite files.

[ Voor 6% gewijzigd door Anoniem: 303530 op 31-03-2011 16:06 ]

[Alexxxxxxxxxx]

Ik heb hier ook last van...

[Bee.nl]

Anoniem: 303530 schreef op dinsdag 29 maart 2011 @ 01:22:
Na nog wat tests is het volgende duidelijk geworden:

inloggen: geen probleem
adblock plus: geen probleem
beiden: na een uur 300MB memory geleakt.

Naar aanleiding van jouw conclusie dat de memory leak veroorzaakt wordt door een combinatie van sessies en ABP, ben ik zelf nog eens aan de slag gegaan. Ik wilde kijken of ik jouw conclusie kon bevestigen dan wel ontkrachten

Voor de test heb ik een nieuwe VM aangemaakt met daarop een verse installatie van Windows 7 x64. Vervolgens heb ik er Firefox 4.0 opgezet met een schoon profiel. Voor de test heb ik ABP 1.3.5 gebruikt; geen plugins dus. Na het maken van 6 runs met jouw script is dit het resultaat:



Eerst heb ik een paar baseline configuraties getest: ingelogd (blauw) en uitgelogd (groen). Daarna heb ik de combo ingelogd+ABP (rood) getest. Bij de eerste run kreeg ik een mooie stijgende lijn te zien, een memory leak! Dit resultaat heb ik geprobeerd te reproduceren door nog eens 3 runs (paars, lichtblauw, oranje) te maken met deze configuratie, maar het is me niet gelukt De paarse lijn ligt wel wat hoger, maar dat kwam omdat er opeens een topic voorbij kwam met wat high-res pics.

Dus wat mij betreft is jouw conclusie nog niet helemaal sluitend. Wellicht speelt er nog een element mee. Het enige verschil tussen onze installaties is dat jij (Darkstone) je eigen profiel (met nog andere add-ons/plugins?) hebt overgezet, terwijl ik een schoon profiel heb gebruikt

[Anoniem: 303530]

Ik heb mijn eigen profiel gebruikt en vervolgens alles eruit gesloopt wat volgens mij niets te maken had met de leak. Ik heb nu deze resultaten:
(ik ben er overigens mee gestopt, met de huidige test setup, omdat je moeilijker nog consistentere resultaten kan krijgen dan deze)



Zo consistent als maar kan, alleen de oranje lijn doet vaag maar ik kan me niet meer herrineren wat ik daar precies anders heb gedaan, misschien gedraaid tijdens een wat rustiger HK moment? Daar komen die spikes iig vandaan...

Trouwens, ik dacht dat je op GoT ergens een interface had om je cookies te bekijken anex verwijderen, weet iemand nog welke URL dat is?


"Alles eruit gesloopt" wil overigens zeggen: persona's, alle plug-ins, en alle addons disable'd. Ik had op dat moment ook geen flash & silverlight geinstaleed.

[ Voor 10% gewijzigd door Anoniem: 303530 op 31-03-2011 22:51 ]

[Bee.nl]

Anoniem: 303530 schreef op donderdag 31 maart 2011 @ 22:50:
Trouwens, ik dacht dat je op GoT ergens een interface had om je cookies te bekijken anex verwijderen, weet iemand nog welke URL dat is?

Bedoel je deze pagina?

Maar hoe bedoel je gestopt... heb je een andere test setup gevonden of denk je dat je er wel uit bent qua oorzaak

[The_Worst]

Ik denk deze:
http://gathering.tweakers.net/forum/cookiemonster

[Anoniem: 303530]

Bee.nl schreef op donderdag 31 maart 2011 @ 22:53:Maar hoe bedoel je gestopt... heb je een andere test setup gevonden of denk je dat je er wel uit bent qua oorzaak

Ik ben gestopt met de huidige test setup omdat de oorzaak voor mij 100% helder is: adblock.
Of eigenlijk moet ik nog eens gaan uitzoeken wat precies de correlatie is tussen inloggen en de memory leak, maar dat lijkt mij vrij moeilijk zonder verregaande kennis van de backend van t.net.

maw: i'm out of idea's

The_Worst schreef op donderdag 31 maart 2011 @ 22:56:
Ik denk deze:
http://gathering.tweakers.net/forum/cookiemonster

Die zocht ik ja! Helaas kan je niet zoveel verwijderen als ik dacht.

[- J.W. -]

Op adblock forum is er ook wat gaande over ABP icm geheugen vrijgeven.

developer:
"Yes, I could confirm that our redirect detection hack delays garbage collection. Right now I am looking into ways to fix that."

[ Voor 45% gewijzigd door - J.W. - op 31-03-2011 23:15 ]

[Bee.nl]

- J.W. - schreef op donderdag 31 maart 2011 @ 23:14:
Op adblock forum is er ook wat gaande over ABP icm geheugen vrijgeven.

developer:
"Yes, I could confirm that our redirect detection hack delays garbage collection. Right now I am looking into ways to fix that."

Ja, ik was het ook net aan het lezen. Schijnt dat de Garbage Collector vertraging oploopt bij het gebruik van bepaalde add-ons, waaronder ABP dus. Zie ook de bugtracker van Mozilla.

De devbuild van ABP 1.3.6 schijnt daar al een fix voor te hebben. Ik ga die versie eens installeren en ik zal het geheugengebruik eens in de gaten houden.

Fixed: Redirect blocking feature has a negative impact on memory management in Firefox.

[ Voor 19% gewijzigd door Bee.nl op 31-03-2011 23:21 ]

[Anoniem: 303530]

Mooie term ook, "vertraging" bij iets wat gewoon honderden megabytes in een uur opslokt

Maar goed, fijn om na maanden draaikonten te horen dat er iemand mee bezig is.

edit:

Bee.nl schreef op donderdag 31 maart 2011 @ 23:17:
De devbuild van ABP 1.3.6 schijnt daar al een fix voor te hebben. Ik ga die versie eens installeren en ik zal het geheugengebruik eens in de gaten houden.


[...]

* Anoniem: 303530 slingert zijn VM weer aan.

[ Voor 52% gewijzigd door Anoniem: 303530 op 31-03-2011 23:32 ]

[Cloud]

Dat is goed nieuws zeg, want iedereen gaf simpelweg Mozilla de schuld steeds. Terwijl het eigenlijk best duidelijk is dat APB ermee te maken heeft.

[Patriot]

Cloud schreef op donderdag 31 maart 2011 @ 23:30:
Dat is goed nieuws zeg, want iedereen gaf simpelweg Mozilla de schuld steeds. Terwijl het eigenlijk best duidelijk is dat APB ermee te maken heeft.

Mja dat zegt helaas niet zoveel over wie er 'schuldig' is aan dit euvel. Als ABP op een normale manier gebruik maakt van de API die Mozilla levert en daar zit een memleak in, dan kun je moeilijk ABP de schuld geven. Als ABP iets doet waardoor er steeds meer geheugen gebruikt wordt dan zijn zij juist weer de hoofdschuldige

[Bee.nl]

In de link naar de bugtracker staat wel een interessante discussie over de (mogelijke) oorzaken van de memory leak(s). Ik heb er even twee relevante stukjes uitgevist:

Boris Zbarsky:
Worse yet, even if you close the tab you might leak permanently: channels don't participate in cycle collection, so if there's a ref through the node you stuck on the channel to the document that was loaded from the channel you will get a permanent leak.

Wladimir Palant : (ABP developer)
[..] So there are two issues here. First was keeping DOM nodes alive which in this test caused delays of 2-3 ms (that's what I've seen in Firefox 4 and fixed now). The other was having many objects in memory - that's Adblock Plus filter data which is still causing significant delays in Firefox 3.6 (proportional to the number of filters) while having basically no impact in Firefox 4 (thanks to compartments I guess). [..]

De test waar ze het over hebben is deze pagina. Ik heb er zelf ook even mee zitten spelen. Met de nieuwe ABP is de GC delay bij mij ~10ms lager. Door met alle js-tools tegelijk te spelen op die site kun je het geheugengebruik van FF enorm opkrikken. Als het goed is - en dat is hier het geval - wordt het ongebruikte geheugen vrij snel (na zo'n 5 seconden) weer opgeruimd.

[Cloud]

Patriot schreef op donderdag 31 maart 2011 @ 23:51:
[...]

Mja dat zegt helaas niet zoveel over wie er 'schuldig' is aan dit euvel. Als ABP op een normale manier gebruik maakt van de API die Mozilla levert en daar zit een memleak in, dan kun je moeilijk ABP de schuld geven. Als ABP iets doet waardoor er steeds meer geheugen gebruikt wordt dan zijn zij juist weer de hoofdschuldige

Natuurlijk, er zijn bepaalde addons die hier last van hebben. En ookal ligt de echte oorzaak bij Mozilla, de addon makers kunnen het beste zeggen waar het nou eigenlijk fout gaat. Hoe dan ook, zegt zo'n bugreport van een ontwikkelaar wat meer dan van $randomuser.

[Anoniem: 303530]

Ik ga eerst naar bed, maar zoals het er nu uit ziet is het opgelost met de dev build. Met ABP en ingelogd hier blijft het geheugengebruik relatief constant in plaats van dat er na een uur 100~300MB ram verdwenen is. Het geheugengebruik in zijn algemeen is wel wat hoger (+20MB?) maar daar is nog niet zoveel zinnigs over te zeggen met n=1.

Nu nog nog wachten op de real life tests. Het ziet er iig veelbelovend uit.

[Smultie]

Zou geweldig nieuws zijn. Versie 1.3.6 komt overigens maandag uit.
Zie ook http://adblockplus.org/de...-to-be-released-on-monday

[ Voor 47% gewijzigd door Smultie op 01-04-2011 10:02 ]

[Cloud]

Ik heb voordat ik aan de slag ging die devbuild erop gezet. Het geheugengebruik lijkt mee te vallen, maar over een aantal uurtjes kan ik het met zekerheid zeggen. Ben wel vergeten de grafiek te laten draaien, dus kan niet een mooi lijntje tekenen deze keer.

[- J.W. -]

Het is nog niet (helemaal?) over.

Met ABP 1.3.6 RC:



Door de grote uithalen lijkt het misschien redelijk vlak maar het geheugengebruik is gestegen van ~275 naar ~680 gedurende ~7,5 uur.

FF4.0 32 bit + 14 add-ons + flash, etc, Win 7 64 bit

[ Voor 6% gewijzigd door - J.W. - op 01-04-2011 17:40 . Reden: update ]

[Cloud]

Mijn werkdag zit er bijna op en Firefox zit nu op een 400 MB geheugengebruik. Wel verhoogd dus, maar ik hoef Firefox niet meer te herstarten halverwege de dag omdat hij bovende 600-700 MB geheugengebruik gaat nemen. Dus alhoewel het misschien niet opgelost is, lijkt het wel een flink stuk verbeterd met die devbuild.

[KiPKaKDutcH]

Anoniem: 303530 schreef op vrijdag 01 april 2011 @ 00:44:
Ik ga eerst naar bed, maar zoals het er nu uit ziet is het opgelost met de dev build. Met ABP en ingelogd hier blijft het geheugengebruik relatief constant in plaats van dat er na een uur 100~300MB ram verdwenen is. Het geheugengebruik in zijn algemeen is wel wat hoger (+20MB?) maar daar is nog niet zoveel zinnigs over te zeggen met n=1.

Nu nog nog wachten op de real life tests. Het ziet er iig veelbelovend uit.

Net geïnstalleerd. Zal me verbruik controleren bij hoe ik normaal surf.

[Bee.nl]

Na een dag draaien met ABP 1.3.6rc.2952 is dit het resultaat:

Windows 7 x64 met Firefox 4.0

Ik heb dit keer mijn eigen profiel overgezet en 2 runs gemaakt met de nieuwe devbuild van ABP. Het geheugengebruik is nu een stuk stabieler dan voorheen. Het ligt nu grofweg tussen de 300MB en 400MB, wat op zich al een verbetering is. Voorheen liep het na een paar uur al tegen de 600 à 700MB aan. Toch is er nog een licht stijgende trend te zien, dus wellicht zijn er nog meer leaks.

[KiPKaKDutcH]

Heb de devbuild van ABP ook geïnstalleerd. Gebruik zit nu rond de 400MB. Heb hem op +-770MB zien staan. Niet over de 1GB geweest dus Heb vorige week nieuwe profiel gemaakt, bladwijzers wel eerst gesaved Maar nu heb ik het ABP logo niet meer naast het Home knopje. Hij staat nu alleen in de add-onbalk die ik uit heb. Iemand oplossing?

ABP in Status weergeven aanvinken -> Add-onbalk aanvinken -> rechterklik @ Firefox -> aanpassen -> ABP logo naar boven slepen -> Klaar. Was het zo simpel? Blijkbaar

edit: W7x64 (4GB), Firefox 4 final. Rest pc specs staat in sig.
edit: ABP fixed. Ram gebruik is nu stabiel en daalt ook snel, veel gebruik.

[ Voor 31% gewijzigd door KiPKaKDutcH op 01-04-2011 20:17 . Reden: edit: ]

[Anoniem: 303530]

ctrl + /

[Anoniem: 303530]

En toen was ABP vrij van memory leaks.



Eindelijk

Nu moet er nog wat worden gedaan aan het exorbitante geheugengebruik van firefox, ik hoorde dat dat met FF5 een speerpunt moest worden.

[woest85]

Darkstone, welke dev build is dat precies?

code:

        <em:version>1.3.6rc.2952</em:version>

van 31-03-2011 leek voor mij geen verschil te maken namelijk

Mhh, gezien bee.nl's post ga ik het eens opnieuw proberen, heb namelijk inmiddels een schoon profiel aangemaakt omdat mijn profiel gisterochtend ook bleef crashen.

[ Voor 34% gewijzigd door woest85 op 01-04-2011 23:15 ]

[Anoniem: 303530]

1.3.6rc.2952

Dezelfde dus, van de link een halve pagina terug.

[woest85]

Anoniem: 303530 schreef op vrijdag 01 april 2011 @ 23:16:
1.3.6rc.2952

Dezelfde dus, van de link een halve pagina terug.

Had hem zelf al een paar dagen eerder draaien, hij update vanzelf ook wel naar nieuwe dev builds. Ga het gewoon maar eens opnieuw proberen.

//edit het schone profiel als toevoeging op enkel de dev build van ABP lijkt voor mij dan toch de oplossing te zijn, ~400MB geheugengebruik atm na ruim 12 uur. Hou het echter nog wel ff in de gaten.

[ Voor 23% gewijzigd door woest85 op 02-04-2011 12:32 ]

[Bee.nl]

woest85 schreef op vrijdag 01 april 2011 @ 23:20:
//edit het schone profiel als toevoeging op enkel de dev build van ABP lijkt voor mij dan toch de oplossing te zijn, ~400MB geheugengebruik atm na ruim 12 uur. Hou het echter nog wel ff in de gaten.

Mooi om te horen dat de nieuwe build bij iedereen een groot verschil maakt. Ik denk dat het hoge geheugengebruik ook deels inherent is aan het ontwerp van Firefox 4. Hopelijk kunnen ze met versie 5 weer een sprong voorwaarts maken wat betreft geheugenmanagement.

[Anoniem: 303530]

We testen lekker door:


...Er lijkt nog een stijgende lijn in te zitten, maar de vraag is in hoeverre je dat na bijna 15 uur merkt.
(het plaatje ziet er overigens erger uit dan het is, trek voor de lol de vergelijking met de blauwe lijn die je hier ziet)

Het volgende plaatje is echter interessanter:


Naas het exorbante aantal schrijfbewerkingen vraag ik me af waarom win32/workingset zo hoog blijft als er maar 188 MB "in use" is, weet iemand hier meer vanaf?

[Cubic X]

Anoniem: 303530 schreef op zaterdag 02 april 2011 @ 20:11:
We testen lekker door:

[afbeelding]
...Er lijkt nog een stijgende lijn in te zitten, maar de vraag is in hoeverre je dat na bijna 15 uur merkt.
(het plaatje ziet er overigens erger uit dan het is, trek voor de lol de vergelijking met de blauwe lijn die je hier ziet)

Het volgende plaatje is echter interessanter:
[afbeelding]

Naas het exorbante aantal schrijfbewerkingen vraag ik me af waarom win32/workingset zo hoog blijft als er maar 188 MB "in use" is, weet iemand hier meer vanaf?

Is de workingset niet gewoon het geheugen dat Windows voor Firefox heeft gereserveerd?

[mcDavid]

Anoniem: 303530 schreef op vrijdag 01 april 2011 @ 22:17:

Nu moet er nog wat worden gedaan aan het exorbitante geheugengebruik van firefox, ik hoorde dat dat met FF5 een speerpunt moest worden.

Ik vind 400 MB nou niet bepaald exorbitant ofzo.

[Anoniem: 303530]

Cubic X schreef op zondag 03 april 2011 @ 10:22:
[...]

Is de workingset niet gewoon het geheugen dat Windows voor Firefox heeft gereserveerd?

Klopt.

[ovigo]

@ mcDavid: Voor een browser? Vind ik het toch wel aan de hoge kant. 5 jaar geleden klaagde men nog dat Fx wel 40 MB geheugen gebruikte(!). OK, Moore's Law etc, maar toch wel aan de hoge kant voor een programma waarvan de functionaliteit toch niet bepaald ver10voudigd is.

[D!zzy]

Is er een mogelijkheid om te loggen in Mac OSX? Ben wel benieuwd.
Zonet ook even de devbuild van Adblock Plus geïnstalleerd.

[Anoniem: 303530]

Vast wel, ik ben alleen niet zo'n held met bash.

[Lizard]

De final van adblock plus 1.3.6 is nu ook hier te vinden.

[Anoniem: 787]

Ik heb ook de ervaring dat FireFox dan heel traag afsluit: het duurt minuten voordat die 700 MB geheugen is opgeruimd en FireFox verdwijnt uit Taakbeheer. Vaak zie ik het geheugengebruik zelfs stijgen, bij het afsluiten.
...en dat met twee websites open. N.B.: ik gebruik geen AdBlock.

(Vroeger kon je FireFox even minimaliseren om overbodig geheugengebruik te stoppen).

[Tarabass]

Anoniem: 787 schreef op maandag 04 april 2011 @ 10:42:
Ik heb ook de ervaring dat FireFox dan heel traag afsluit: het duurt minuten voordat die 700 MB geheugen is opgeruimd en FireFox verdwijnt uit Taakbeheer. Vaak zie ik het geheugengebruik zelfs stijgen, bij het afsluiten.
...en dat met twee websites open. N.B.: ik gebruik geen AdBlock.

(Vroeger kon je FireFox even minimaliseren om overbodig geheugengebruik te stoppen).

Kan nog steeds -> klik

[Stay1ed]

Met een kleine schop en een afbeelding van mijn geheugenverloop hoop ik dit topic weer tot leven te wekken:



Zoals te zien heb ik weinig last van geheugenlekken. Win7 32bit, Firefox 4, ABP 1.3.6, DownloadHelper 4.8.6 en Stylish 1.1.

[user109731]

Even een kick. Misschien interessant om een nieuwe grafiek te genereren met Firefox 5 vs. Aurora (FF 7). Het geheugengebruik in FF7 is flink aangepakt, vooral als de browser voor lange tijd open staat...

http://www.mozilla.com/en-US/firefox/channel/

[Anoniem: 303530]

Dat is heel leuk. Maar er is niet een addon die werkt bij mij. Testen gaat dan ook weinig zin hebben .

[Anoniem: 303530]

Toch maar een test:



Blauw: FF 5.0 met ABP, alement hider helper, status-4-evar, firefestures, flashblock, quick locale switcher, restartless firefox, switch to tab no mote, web developper, webmail notifier

Rood: ABP, element hider helper, en status-4-ever. Dat waren de enige die het deden.

Volgens mij is er niets veranderd. Je ziet nog steeds dezelfde stijgende lijn die iets flauwer is, maar ik heb gisteren [met 5.0] een stuk intensiever gesurfd dan vandaag

Ik zet 5.0 er weer op.