Verbesserung der Stabilität des Steam-Clients unter Linux

Verbesserung der Stabilität des Steam-Clients

• Hintergrund: Im Steam-Client-Update vom 5. November wurden einige allgemeine Abstürze unter Linux behoben. Der größte Einflussfaktor darunter war eine Änderung bei der Verwendung der Funktionen setenv und getenv.

• Problem: setenv ist unter Linux eine unsichere API und kann in Multithreading-Umgebungen Probleme verursachen. Nach einem Aufruf von getenv können in einem anderen Thread Abstürze wie SIGABRT auftreten.

• Lösung:

  • Die meisten Aufrufe von setenv wurden entfernt und so refaktoriert, dass die Umgebung beim Starten von Prozessen mit execvpe übergeben wird.
  • Um die Abhängigkeit von getenv zu verringern, werden die Aufrufe zwischengespeichert.
  • Für die verbleibenden Einsatzfälle von setenv wurde ein „Environment Manager“ eingeführt, der beim Start vorab einen ausreichend großen Wertpuffer allokiert.

• Ergebnis: Durch diese Änderungen ist die Häufigkeit von SIGABRT deutlich zurückgegangen. Es handelt sich jedoch nicht um eine perfekte Lösung, und wenn externe Bibliotheken setenv aufrufen, besteht weiterhin Absturzgefahr.

• Ausblick: In glibc wird derzeit untersucht, wie sich dieses Problem lösen lässt, indem die Async-Signal-Sicherheit gewahrt bleibt und gleichzeitig die Nutzung von envp synchronisiert wird. Diese Arbeit ist komplex, aber langfristig soll eine Lösung vorgeschlagen werden, die nicht von der POSIX-Spezifikation abweicht.

[GN⁺]

Hacker-News-Kommentare

• Aufgrund von Stabilitätsproblemen im Grafik-Stack von Red Hat wird ein Patch geprüft

  • Eine Korrektur der Thread-Sicherheit von getenv wird voraussichtlich in glibc 2.41 aufgenommen
  • setenv ist bereits leichter zu behandeln, da Umgebungs-Strings nicht freigegeben werden
  • unsetenv ist wegen Nebenläufigkeitsproblemen kompliziert
  • Der Grund, warum man bei getenv keine Sperren einführen will, ist die Wahrung der Asynchronous-Signal-Safety
  • Wegen vfork+execve ist es schwer, Memory Leaks zu vermeiden, weshalb Änderungen an der Umgebungsverarbeitung umstritten sind

• Dankbarkeit dafür, dass Steam unter Linux gut funktioniert

• Am besten liest man Umgebungsvariablen beim Booten ein und verwendet setenv nicht

  • Beim Erzeugen neuer Prozesse sollte man die aktuelle Umgebung duplizieren und die neuen Werte aktualisieren
  • Die Verwendung von getenv/setenv als IPC-Messaging-Mechanismus kann problematisch sein

• Es gibt Zweifel daran, ob setenv eine Linux-API ist

  • setenv ist in POSIX definiert und wird nicht im Linux-Kernel, sondern im User Space implementiert

• Es gibt die Frage, ob Programme Fälle haben, in denen ein Thread setenv aufruft und ein anderer Thread die Wirkung sehen soll

  • GLIBC dokumentiert riskante Funktionen gut, daher könnte man Sperren/Kopien hinzufügen

• Es gibt ein Problem, bei dem Steam sich darüber beschwert, dass keine Verbindung besteht

  • Wenn man mehrmals auf den Button „Erneut versuchen“ klickt, funktioniert es, aber es ist umständlich

• Die Einblicke in den Steam-Client und Linux-Programmierung sind interessant

  • Man versteht, warum die Release Notes nicht detailliert sind, aber „allgemeine Absturzbehebungen“ ist eine untertreibende Formulierung

• Um das Problem in glibc zu lösen, könnten funktionale Kompromisse nötig sein

  • Wenn sich langfristig ein vernünftiger Vorschlag machen lässt, könnte man ihn verfolgen

• Die Rendering-Performance des Steam-Clients ist schlecht, wenn sich die Maus im Fenster befindet

• Es gibt einen seit Langem bestehenden Bug im Linux-Steam-Client

  • Wenn Steam länger als einen Tag läuft, gehen die Fenster-Handles aus, sodass sich keine neuen Grafik-Anwendungen/Fenster öffnen lassen
  • Bei Nutzung von Steam Chat tritt das Problem schneller auf
  • Das Problem ist auf GitHub dokumentiert, wurde aber ohne ersichtlichen Grund geschlossen
  • Man startet Steam deshalb persönlich jeden Tag neu
  • Dieses Problem wurde unter KDE/Wayland und auch unter X11 beobachtet