Amélioration de la stabilité du client Steam sous Linux

Amélioration de la stabilité du client Steam

• Contexte : la mise à jour du client Steam du 5 novembre a corrigé des plantages courants sous Linux. Parmi eux, le plus marquant concernait un changement dans la manière d’utiliser les fonctions setenv et getenv.

• Problème : setenv est une API non sûre sous Linux, dont l’utilisation peut poser problème dans un environnement multithread. Après un appel à getenv, des plantages comme SIGABRT peuvent survenir dans un autre thread.

• Solution :

  • suppression de la plupart des appels à setenv, avec une refactorisation pour transmettre l’environnement lors de la création du processus via execvpe.
  • mise en cache des appels afin de réduire la dépendance à getenv.
  • pour les cas restants d’utilisation de setenv, introduction d’un « gestionnaire d’environnement » qui préalloue au démarrage un tampon de valeurs suffisamment grand.

• Résultat : ces changements ont fortement réduit la fréquence des occurrences de SIGABRT. Ce n’est toutefois pas une solution parfaite, et il subsiste un risque de plantage si des bibliothèques externes appellent setenv.

• Plan futur : dans glibc, des recherches sont en cours pour résoudre ce problème en maintenant la sûreté asynchrone des signaux tout en synchronisant l’usage de envp. Ce travail est complexe, mais l’objectif est de proposer à long terme une solution qui reste dans le cadre de la spécification POSIX.

[GN⁺]

Avis Hacker News

• Un correctif est à l’étude en raison de problèmes de stabilité de la pile graphique de Red Hat

  • Il est très probable qu’une correction de la sûreté des threads de getenv soit incluse dans glibc 2.41
  • setenv est déjà plus simple à traiter, car il ne libère pas les chaînes d’environnement
  • unsetenv est complexe à cause des problèmes de concurrence
  • La raison pour laquelle on ne veut pas introduire de verrouillage dans getenv est de préserver la sûreté vis-à-vis des signaux asynchrones
  • En raison de vfork+execve, il est difficile d’éviter les fuites mémoire, ce qui rend controversées les modifications de la gestion de l’environnement

• Reconnaissance que Steam fonctionne bien sous Linux

• La meilleure approche est de lire les variables d’environnement au démarrage et de ne pas utiliser setenv

  • Lors de la création d’un nouveau processus, il faut dupliquer l’environnement actuel puis mettre à jour les nouvelles valeurs
  • Utiliser getenv/setenv comme mécanisme de messagerie IPC peut poser problème

• Question sur le fait de savoir si setenv fait partie de l’API Linux

  • setenv est défini par POSIX et implémenté en espace utilisateur, pas dans le noyau Linux

• Question sur l’existence de cas où un programme appelle setenv dans un thread et attend un effet dans un autre thread

  • GLIBC documente déjà bien les fonctions dangereuses, donc il serait possible d’ajouter du verrouillage/de la copie

• Problème où Steam se plaint de ne pas avoir de connexion

  • En appuyant plusieurs fois sur le bouton « Réessayer », cela finit par fonctionner, mais c’est pénible

• Les éclairages sur le client Steam et la programmation Linux sont intéressants

  • On comprend pourquoi les notes de version ne sont pas détaillées, mais « corrections générales de crashs » est une formulation qui minimise le sujet

• Résoudre le problème dans glibc pourrait nécessiter des compromis de fonctionnalité

  • Cela pourrait être poursuivi à long terme si une proposition raisonnable peut être faite

• Les performances de rendu du client Steam sont mauvaises lorsque la souris est dans la fenêtre

• Il existe un bug de longue date dans le client Steam sous Linux

  • Si Steam reste lancé plus d’une journée, les handles de fenêtre finissent par s’épuiser, empêchant l’ouverture de nouvelles applications/fenêtres graphiques
  • L’utilisation de Steam Chat fait apparaître le problème plus rapidement
  • Ce problème est documenté sur GitHub, mais a été fermé sans raison
  • Personnellement, redémarrer Steam chaque jour est devenu une habitude
  • Ce problème a aussi été observé avec KDE/Wayland et sous X11