Mejoras de estabilidad del cliente de Steam en Linux

Mejoras de estabilidad del cliente de Steam

• Contexto: En la actualización del cliente de Steam del 5 de noviembre se corrigieron fallos comunes en Linux. Entre ellos, el cambio con mayor impacto fue la modificación en la forma de usar las funciones setenv y getenv.

• Problema: setenv es una API insegura en Linux, y puede causar problemas cuando se usa en entornos multihilo. Después de una llamada a getenv, pueden producirse fallos como SIGABRT en otro hilo.

• Solución:

  • Se eliminaron la mayoría de las llamadas a setenv y se refactorizó para pasar el entorno al crear procesos usando execvpe.
  • Se almacenan en caché las llamadas para reducir la dependencia de getenv.
  • Para los casos restantes de uso de setenv, se introdujo un "administrador de entorno" que preasigna al inicio un búfer de valores lo suficientemente grande.

• Resultado: Estos cambios redujeron de forma importante la frecuencia de aparición de SIGABRT. Sin embargo, no es una solución perfecta, y sigue existiendo riesgo de fallos si bibliotecas externas llaman a setenv.

• Próximos pasos: En glibc están investigando cómo resolver este problema manteniendo la seguridad asincrónica de señales y sincronizándolo con el uso de envp. Es un trabajo complejo, pero a largo plazo planean proponer una solución sin apartarse de la especificación POSIX.

[GN⁺]

Opiniones en Hacker News

• Se está revisando un parche debido a problemas de estabilidad en la pila gráfica de Red Hat

  • Es muy probable que una corrección de seguridad de hilos para getenv se incluya en glibc 2.41
  • setenv ya es más fácil de manejar porque no libera las cadenas del entorno
  • unsetenv es complicado por problemas de concurrencia
  • La razón para no introducir bloqueos en getenv es mantener la seguridad ante señales asíncronas
  • Debido a vfork+execve, es difícil evitar fugas de memoria, por lo que modificar el manejo del entorno es un tema polémico

• Agradecen que Steam funcione bien en Linux

• Lo mejor es leer las variables de entorno al arrancar y no usar setenv

  • Al crear un proceso nuevo, se debería clonar el entorno actual y actualizar los nuevos valores
  • Usar getenv/setenv como mecanismo de mensajería IPC puede causar problemas

• Hay dudas sobre si setenv es una API de Linux

  • setenv está definido en POSIX y se implementa en espacio de usuario, no en el kernel de Linux

• Se pregunta si realmente hay casos en los que un programa llama a setenv en un hilo y espera el efecto en otro hilo

  • GLIBC documenta bien las funciones peligrosas, así que se podrían agregar bloqueos/copias

• Hay un problema en el que Steam se queja de que no hay conexión

  • Si se presiona varias veces el botón de "reintentar", termina funcionando, pero es incómodo

• Resultan interesantes las observaciones sobre el cliente de Steam y la programación en Linux

  • Se entiende por qué las notas de la versión no son detalladas, pero "correcciones generales de fallos" es una forma de decirlo que se queda corta

• Resolver el problema en glibc podría requerir concesiones en funcionalidad

  • A largo plazo, podría valer la pena seguir adelante si se puede plantear una propuesta razonable

• El rendimiento de renderizado del cliente de Steam es malo cuando el mouse está dentro de la ventana

• Hay un bug de larga data en el cliente de Steam para Linux

  • Si Steam permanece ejecutándose más de un día, se agotan los handles de ventana y ya no se pueden abrir nuevas aplicaciones o ventanas gráficas
  • Si se usa Steam Chat, el problema aparece más rápido
  • Este problema está documentado en GitHub, pero fue cerrado sin motivo aparente
  • En lo personal, reinician Steam todos los días
  • Este problema también se ha observado en KDE/Wayland y en X11