GNOME-Shell Speicherleck

Screenshot: ft

 

Das GNOME-Shell Speicherleck, das in den letzten GNOME-Versionen unrühmliche Bekanntheit erlangte und vor über einem Jahr erstmals in einem Bugrepot im Launchpad auftauchte, ist geschlossen. Das berichtet GNOME-Entwickler Georges Stavracas in seinem Blog. In dem teilweise recht technischen Bericht erläutert er, wie er dem Leck auf die Spur kam und einen Weg fand, das Speicherleck, das diesen Namen eigentlich gar nicht verdient, zu stopfen. Die jetzt verfügbare Fehlerbereinigung wird gerade in den Git-Zweig für GNOME 3.30 eingeführt. Wenn sich der Patch bewährt, soll er auch auf GNOME 3.28 zurückportiert werden.

Schnell ausgelöst

Das Speicherleck kann durch alltägliche Arbeitsschritte wie das Wechseln einer Anwendung per ALT-TAB ausgelöst werden. Dabei werden mit der Zeit große Teile des Arbeitsspeichers belegt, aber nicht wieder freigegeben. Ein Kommentar von GNOME-Entwicklerkollege Carlos Garnacho brachte Stavracas schließlich auf die richtige Spur. Der Täter konte in der Garbage Collection (GC) der GNOME-Javascript-Bindings  (GJS) dingfest gemacht werden. GC ist ein Mechanismus, der nicht nur dort dafür sorgt, dass nicht mehr benötigte Objekte aus demn Speicher entsorgt werden. Viele Anwender kennen den Begriff der Garbage Collection vermutlich hauptsächlich vom Löschprozess bei Solid State Disks (SSD).

Müllentsorgungsproblem

Das Problem bestand darin, dass eine GC nicht immer dann ausgelöst wurde, wenn es nötig gewesen wäre und somit der belegte Speicher anwuchs. Bei JavaScript kennen Objekte ihre Abhängigkeiten, in C kennt ein Objekt nur deren Anzahl. Deshalb wurden GObjects von der GC nicht entsprechend abgeräumt. Die jetzt implementierte Lösung scheint zwar radikal, ist aber nicht so invasiv wie es sich anhört. Künftig wird jedes Mal wenn ein GObjekt zum Entfernen markiert wird, gleichzeitig eine GC eingeplant. Das hat nach ersten Tests lediglich einen wesentlich kleineren Einfluss auf die Gesamt-Performance als zu erwarten wäre.

Rückportierung auf 3.28 vorgesehen

Die Fehlerbereinigung dieses vermeintlichen Speicherlecks wird erst mit GNOME 3.30 im Herbst offiziell erscheinen. Ubuntu hatte vor einigen Tagen bereits dazu aufgerufen, eine bereits verfügbare vorläufige Lösung möglichst ausgiebig zu testen, in der Hoffnung, der Fix könne noch in das am Donnerstag, dem 26. April erscheinende Ubuntu 18.04 LTS »Bionic Beaver« einfließen. Auch wenn eine Rückportierung auf GNOME 3.28 geplant ist, könnte es hierfür jedoch zu spät sein.

Verwandte Themen

KDE Neon auf Ubuntu 18.04 aktualisiert
views 708
 Screenshot: ft Worauf viele Anwender der »Bleeding Edge«-Distribution KDE Neon gewartet haben, ist nun eingetreten: Der Unterb...
Ubuntu 18.04.1 LTS erschienen
views 651
Screenshot: ftWie gewohnt hat Canonical nach drei Monaten ein erstes Update für Ubuntu 18.04 LTS »Bionic Beaver« herausgegeben. Die Aktualisierun...
Ubuntu: Bericht über Ergebnisse der Datensammlung ...
views 324
Quelle: Ubuntu-BlogCanonical hat einen ersten Bericht über die Ergebnisse der Datensammlung veröffentlicht, die mit Ubuntu 18.04 LTS  »Bionic Bea...
Fedora 28 mit viel Innovation
views 545
Screenshot: ftFedora 28 ist in den Varianten Workstation, Server und Cloud erschienen. Wir schauen, was in Fedora 28 Workstation neu ist. Fedora is...
Ubuntu und der Datenschutz
views 2.4k
Photo by Dayne Topkin on UnsplashWindows 10 ist, was den Datenschutz und den Schutz der Privatsphäre im Allgemeinen angeht, eine Katastrophe. Mic...

Beitrag kommentieren