Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 59 reacties

Mozilla heeft kort na het uitbrengen van Firefox 3.6.4 een nieuwe update van zijn browser uitgebracht. Firefox 3.6.6 verhoogt daarmee de timeout-waarde van de crash protection-feature van 10 seconden naar 45 seconden.

Firefox 3.6.4 werd vorige week door Mozilla uitgebracht. De browser-update voorzag Windows- en Linux-gebruikers van crash protection. Dit mechanisme, waarbij plugins in een eigen proces draaien, moet voorkomen dat een crashende plugin de gehele browser onderuit haalt. Enkele andere browsers, waaronder Google Chrome, beschikken al langer over deze feature.

Inmiddels heeft Mozilla binnen een week versie 3.6.6 uitgebracht. Volgens Mozilla was de update nodig omdat de timeout-waarde van de crash protection te laag bleek voor gebruikers van met name oudere hardware. Dit zou onder andere zichtbaar worden bij het inladen van Flash-games. Om het probleem te verhelpen, heeft Mozilla de timeout in versie 3.6.6 opgehoogd: in plaats van 10 seconden zal Firefox voortaan 45 seconden wachten voordat het een vastgelopen plugin uitschakelt en een foutmelding toont.

Moderatie-faq Wijzig weergave

Reacties (59)

45 Seconden is dus op minder oude hardware wel wat lang. Je kunt in about:config de waarde dom.ipc.plugins.timeoutSecs weer wat omlaag schroeven :)
Ah, dat vroeg ik me dus af. In feite hebben ze alleen de default setting veranderd? Of waren die 10 seconden eerst hardcoded ofzo?
In mijn 3.6.4 staat die waarde gewoon op 10 ja :)
Ik had hier laatst inderdaad aldoor last van. Flash-applicaties die zogenaamd gecrasht zijn. Sowieso lijkt me een time-out systeem überhaupt niet lekker. Indien een flash-applicatie dus op iets moet wachten krijg je ineens een crashmelding te zien. Is er niet een betere manier om vast te stellen dat een applicatie écht hangt?
Indien een flash-applicatie dus op iets moet wachten krijg je ineens een crashmelding te zien. Is er niet een betere manier om vast te stellen dat een applicatie écht hangt?
Als een applicatie hangt, het maakt weinig uit of dat een normaal programma is, of een plugin in een browser, dan antwoord ie niet meer op calls van het bovenhangende proces. Ergo, een timeout is de enige methode om het vast te stellen. Je stuurt de vraag: leef je nog ( gedefineerd in iedere plugin API)? En indien na <x> geen antwoord (antwoord sturen is verplicht, en wel onmiddelijk) kun je er veilig van uit gaan dat 't dood is. Je ziet onder Windows en Mac OS X ook: "application not responding" als zoiets met een applicatie gebeurt. Onder Linux/Unix is het wat moeilijker, maar 1 methode om ze te spotten is door op jacht te gaan naar processes die lange tijd Zombie state hebben.

Als je timeout te kort staat, kun je veel te snel apps markeren als 'dood', zoals hier ook het geval is. (en in het geval van een OS, apache zie je ook vaak een zombie worden als een apache child klaar is met requests an gaat afsluiten, bijvoorbeeld bij een graceful restart)
Een zombieproces is eigenlijk al dood, maar het wacht slecht nog op bevestiging van een ouder/grootouder. Naar zombies kijken heeft imho dan ook geen zin, hoogstens naar de ouder kijken. In mijn praktijk is de ouder een beetje brak geprogrammeerd en heeft het sterven van zijn kind gemist.
Een zombieproces is eigenlijk al dood, maar het wacht slecht nog op bevestiging van een ouder/grootouder. Naar zombies kijken heeft imho dan ook geen zin, hoogstens naar de ouder kijken. In mijn praktijk is de ouder een beetje brak geprogrammeerd en heeft het sterven van zijn kind gemist.
Niet alle systemen werken hetzelfde als het om Zombies gaat. Wat jij omschrijft is POSIX, en wat mij betreft de enige juiste methode.

Toch zijn er uitzonderingen op de regel, en gevallen waarbij de ouder al weg is, maar er nog zombie kinderjes ronddwalen. Vergis je niet in het detecteren van die dingen, ze kunnen een indicator zijn van grove problemen. En zombies nemen nog wel degelijk memory space in beslag. Het enige redmiddel ertegen is een reboot helaas, dus detecteren en voorkomen is best boeiend. (toegegeven, echte zombies ben ik al zeker 4 jaar niet meer tegengekomen)
Als je timeout te kort staat, kun je veel te snel apps markeren als 'dood'
Ja ok, maar dit mes snijdt aan twee kanten. Doordat de timeout wordt verlengd worden de programmeurs niet geprikkeld het te verbeteren.

10 seconden is eigenlijk een eeuwigheid in computing. Denk er maar eens over na, met een 1Ghz processor hebben we het over 10 miljard 'omwentelingen' van de processor. De meeste berekeningen kosten tussen de 1 en 10 omwentelingen dus de processor kan minimaal een miljard berekeningen maken in die tijd. Met de internet verbindingen van tegenwoordig kan er ruim een megabyte worden verstuurd, misschien wel 10 of meer megabyte.

Wat staat zo'n plugin in godsnaam te doen???

Het antwoord is dat de schrijver van de plugin slordig is en de plugin eigenlijk niets (!) staat te doen. Deze staat gewoon te wachten. Men is te lui om iets asynchroon te doen met een callback of parallel met een thread, dus doet men het gewoon synchroon, single-threaded, met als resultaat dat de plugin, hoewel hij geen zak uitvoert, ook niet reageert.

Timeouts en crash meldingen zouden er voor zorgen dat of de programmeurs van de plugin aan het werk gaan om dit te verbeteren, of de gebruikers op zoek zouden gaan naar betere plugins. De timeout opschroeven betekent gewoon dat we allemaal langer moeten wachten (omdat het nooit gefixed wordt) en langzaam slibben onze systemen dicht met rotzooi.

* OddesE hates Adobe because both Flash and Acrobat Reader are system hogging, resource eating pieces of cr*p!
Denk er maar eens over na, met een 1Ghz processor hebben we het over 10 miljard 'omwentelingen' van de processor.
1MHz = 1 miljoen berekeningen (per seconde)
1000MHz (1GHz) = 1 miljard berekeningen (per seconde).

Voor de rest heb je overigens volkomen gelijk.
Slimmerd, zijn voorbeeld ging over 10 seconden ergo 10 miljard berekeningen.
Ik weet niet precies hoe dit technisch geïmpementeerd is, maar over het algemeen geldt zo'n timeout als een applicatie/plugin niet reageert op calls er naar toe. Als adobe flash dus fatsoendelijk zou programmeren, dan zou het antwoord kunnen geven ook al zit het ergens op te wachten.
Nou ik kreeg dus deze crashes bij FrontierVille op een ietwat oudere computer, waarbij het allemaal wat langer duurt. Dus puur op tijd denk ik.
tuurlijk puur op tijd: Firefox merkt dat de plugin niets aan het doen is: ofwel zit die te wachten op iets, ofwel is hij vastgelopen. In het laatste geval is het zeker een crash, in het eerste geval misschien (als er bv gewacht wordt op iets dat niet kan voorkomen).

Mozilla heeft (imo terecht) beslist dat 10 seconden een lang genoege wachttijd is om correcte werking te garanderen.

het zegt imo genoeg dat flash de enige plugin is die niet genoeg heeft aan 10 seconden...

@Damic: 'heeft besilst' is voltooid verleden tijd... die beslissing was echter te veeleisend voor flash, een pugin die de laatste tijd toch behoorlijk wat kritiek krijgt over efficientie, en daar gaat mn post om.

[Reactie gewijzigd door kiang op 27 juni 2010 14:41]

Waar lees jij dat flash de enige plugin is die er last van heeft?
euhm het tis nu 45s geworden en geen 10s, vermtis dat 10s te kort was en sommige timeouts on terecht werden gemarkeerd als een fout.
Op langzame computers ja. Hoe langzaam moet je computer kunnen zijn om nog ondersteund te worden? Allicht dat als je probeert een flash app op een 486 te draaien, dat je het wellicht nog draaiende kan krijgen, maar heeeel traag, en dan is ook die 45s niet lang genoeg meer.
Als ik het zelf geprogrammeerd zou hebben, zou ik het op 10s laten staan, maar een API call implementeren om de timeout te verlengen, zodat een flash app die terecht lang zit te wachten, tegen FF kan vertellen dat dit ok is, en door kunnen draaien. Een gecrashte plugin zal geen calls meer versturen en gewoon gekilled worden.
Dat werkt natuurlijk niet want er zijn al zo'n 20 miljard bestaande pagina's met flash meuk er op en die gaan dus niet hun applicatie allemaal aanpassen aan firefox.

Ik vind 45 seconden ook wel weer lang. De geschiedenis leert dat hoe meer tijd je systemen 'gunt', hoe meer ze ook vreten. Op het moment dat gebruikers gaan klagen omdat ze crash meldingen krijgen wordt een programmeur (of vaker: zijn baas) ook weer gemotiveerd om er wat tijd aan te besteden om het sneller te maken.

Wellicht was een beter compromis geweest om na 10 seconden een melding te geven als: "Een plugin reageert al 10 seconden niet en moet wellicht worden beëindigd. Wilt u de plugin wat meer tijd geven om te reageren?"

Zo kunnen gebruikers van langzame systemen toch verder maar blijft men de ontwikkelaars prikkelen om te zorgen dat dingen goed presteren en niet te traag worden.
+2 - inzichtvol...


vraag alleen is of dat echt gaat werken,

ergens wel weer heel jammer dat mozilla de gemakkelijke uitweg kiests...
en dus de bal niet bij adobe legt. en dan nog van 10 naar 45 sec is wel HEEL erg veel verschil, hadden ze niet beter eerst eens kunnen kijken wat er gebeurd met, bijv 20 sec.. (of hooguit 30)

voor de hele problematische zut zal dat nog niet genoeg zijn, maar mensen die er dan nog last van hebben kunnen altijd nog in about:config gaan neuzen.

[Reactie gewijzigd door i-chat op 28 juni 2010 10:29]

Langzame computers? Dat valt wel mee want ik had er zelf ook last van bij flash filmpjes op bijv youtube. Mijn systeem draait op een i7 920 dus snel zat zou je zeggen.
Ja en als alle plugins zo geprogrammeerd zouden zijn dan zouden die dus allemaal zélf weer moeten detecteren of instanties gecrasht zijn. Tenslotte zou een plugin dan altijd netjes reageren op de call van de browser en zou de browser nooit concluderen dat de plugin 'dood' is, tenzij precies dat stukje dat reageert op de browser crasht. Daarmee verplaats je dus alleen het probleem; je lost helemaal niets op.
Het korte antwoord is: nee.
Het lange antwoord vind je hier: http://en.wikipedia.org/wiki/Halting_problem
Als dit allemaal zo "hardware afhankelijk" is, vraag ik me af waarom er niet een hardware afhankelijke timer in zit, OF dat je deze parameter zelf kunt instellen. Uiteraard met een advies, afhankelijk van de systeemperformance.
dan moet je een check in bouwen in de installer - dat moet je niet willen,

een firefox extentie die flash compatible maakt met oudere systemen zou dan beter zijn,

dus een xpi-tje die niet veel meer doet dan de timmer juist instellen als de default (10s) niet volstaat.
En waar is 3.6.5?
Vreemde redenatie. Snap niet waarom je dat zou willen, twee producten die van hetzelfde versienummeringssysteem gebruik maken.
Het is maar één product, Gecko. Gecko is de motor van een reeks van producten zoals Firefox, Fennec, Thunderbird, Camino etc.

De nummering van Gecko wordt doorgevoerd in sommige producten. Gecko 1.9.4 wordt gebruikt in Firefox 3.6.4 en 1.9.6 in Firefox 3.6.6. Gecko 1.9.5 is alleen gebruikt voor Fennec. Door nu Firefox 3.6.5 over te slaan blijft dit gelijk lopen.
Overgeslagen. Het gaat direct van 3.6.4 naar 3.6.6.
Op de plank naast Winamp 4.
Ondervond zowat geen crashes recent, maar doe ook weining met flash. Probeerde gisteren 3.7a5, maar na een restart was ik weer terug op 3.6.4 even update clicken en ja 3.6.6 is daar. Voor het installeren van een add-ons of nieuwe versie gaat dat lekker snel, maar op mijn werk hebben we nog steeds IE7 en denk dat onze IT guys gek zouden worden van zovaal nieuwe versies. Misschien wat langer testen en gewoon dan pas uitbrengen? Ik kijk uit naar 3.7 als inderdaad mijn GPU ook wordt gebruikt voor wat taken.
Firefox 3.7 is nog in alpha fase, dus deze staat waarschijnlijk geïnstalleerd als "Minefield". Als je dan Firefox opent krijg je dus gewoon de stabiele versie.
denk dat dat wel meevalt, er zijn namelijk verdomd weinig programma's die op FF rusten (deps)

en de firefox versies zelf veranderen ook niet zo veel - die rol je echt zo uit (zolang je niet van major versie wisselt is pro-actief testen met Firefox niet bepaald nodig...

dat is met andere browsers zoals IE wel eens anders (geweest?)
Vanmorgen nog onder FF 3.6.4 gehad. Even een .pdf laden. Hé mijn browser en plugin ChatZilla hangen. Reageren nergens op. OP het moment dat ik de apps wil killen, is er weer leven. Ah de .pdf bleek wel enkele tientallen MB's.

"Display in browser" staat overigens uitgevinkt
Maar waarom kan (wederom Adobe) PDF reader niet gewoon én enkele tientallen MB's aan PDF inladen en wél reageren? Gewoon een kwestie van een threadje open houden om te blijven reageren op events. Dan wordt ook je multi-core CPU eens benut. En dát is dus het probleem: slecht geprogrammeerde software die het wel OK vindt om gewoon vele seconden achter elkaar niet aanspreekbaar te zijn en nergens op te reageren.
het zou handiger zijn geweest om zoals in windows gewoon de mogelijkheid te geven om te wachten tot je plugin klaar is. meestal weet je wel of iets lang nodig heeft om te laden of niet
Het was dus al dom om zo'n timeout hard te coderen ipv er een instelling van te maken, doen ze het bij de reparatie nog een keer ... |:(

@Soldaatje: inderdaad (niet gezien, aan de Chrome tegenwoordig). Wel apart om een nieuwe versie uit te geven voor zo'n kleine instellings wijziging.

[Reactie gewijzigd door TheekAzzaBreek op 27 juni 2010 13:19]

Is niet hardcoded: dom.ipc.plugins.timeoutSecs 45
Het gaat natuurlijk wel om de gebruikersvriendelijkheid. Als mensen merken dat Flash wel goed werkt in Chrome, Internet Explorer of Opera maar niet in Firefox dan heb je een grote kans dat ze gaan overstappen. Met het vrijgeven van deze update doen ze aan damage-control.
Nou ik heb laatst geupdate naar 3.6.4. en ik zie het geheugen gebruik van firefox alsmaar oplopen in de taskmanager. Er zit gewoon een memory leak in. Versie 3.6.3. ook geprobeerd, ook hetzelfde. Ik ben nu tijdelijk overgestapt naar Opera.
Dat zie ik niet. Schakel je plugins eens uit, en check of the Java up to date is.
Start Firefox eens op met veilige modus. Hierdoor zijn alle addons en plugins (?) uitgeschakeld. Als het probleem nu niet optreed dan is het een van de addons die problemen geeft.
Dit dus de reden dat firefox steeds strenger wordt wat betreft de plugins.
Omdat mensen te snel de browser de schuld geven als één van de plugins niet goed werkt.
Ah vandaar dat mijn firefox de laatste week zo vaak crashte, weet ik dat ook weer...
Het hele punt is juist dat add-ons e.d. de browser zelf niet meer kunnen laten crashen, doordat het in een eigen proces draait. Crashte je hele Firefox er uit dan was het zeer waarschijnlijk iets anders. Als Flash nu crasht krijg je dit te zien: http://www.techshout.com/img/shockwave-flash-ss.jpg
Link is dood, en Flash is een plugin niet een add-on :)

Beste is eigenlijk dat ze dit instelbaar maken, via about:config

[Reactie gewijzigd door s.stok op 27 juni 2010 12:58]

idem vond het al zo raar .. x gechecked op virussen spyware etc maar nooit iets gevonden..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True