Hi,

kleiner Tipp am Rande: Lass mal im Hintergrund, aber sichtbar (ideal wäre ein zweiter Bildschirm), in einem Konsolenfenster 'top' mitlaufen und beobachte a) den von Firefox belegten Arbeitsspeicher und b) die Aktivität des kswapd.

Hmm, endlich mal ein richtiger Grund, mich zu überwinden, den Schreibtisch aufzuräumen und den 24-Zöller als Zweitmonitor in Betrieb zu nehmen. :-)

ja, manchmal braucht es nur das richtige Argument. ;-)

Dass der Firefox Speicher frisst, wie Kinder Schokolade, ist ja nichts Neues. Dass der dabei aber das ganze System anhält ...

Das tut er strenggenommen nicht, sondern das tut der swap-Daemon, der irgendwann die Notbremse zieht. Man sieht das in top auch ganz gut, dass der kswapd dann für längere Zeit (fast) 100% CPU frisst.

und mir Mate als Konsequenz mit Marco ein eher von Windows bekanntes Fenster vorblendet, das mich fragt, ob ich auf das nicht antwortende Programm warten oder es abwürgen will, hatte ich noch nicht.

Doch, ich kenne das recht gut. Dieses "$name is not responding" provoziert bei mir manchmal auch caja, der MATE-Dateimanager, wenn er meint, er müsse für die 1294 Bilddateien im Verzeichnis mal schnell die Thumbnails erstellen (obwohl ich zumindest die Anzeige von Thumbnails abgestellt habe).

Wie gesagt, das kenne ich grundsätzlich, es hatte aber nie die von mir am Wochenende beobachteten Konsequenzen**[edit], zumal es die (von mir undokumentierte) JS-Fehlermeldung gab[/edit]**.

Vielleicht ist das Zusammentreffen mit CKs letzten Änderungen Zufall. Vielleicht macht sein JS jetzt aber auch irgendwas, wozu der FF besonders viel RAM zu brauchen glaubt, so dass der Effekt nun schneller eintritt als vorher.

So long,
 Martin