LinuxでSteamクライアントの安定性を改善

 (ttimo.typepad.com)
2 ポイント 投稿者 GN⁺ 2024-11-12 | 1件のコメント | WhatsAppで共有

Steamクライアントの安定性改善

  • 背景: 11月5日のSteamクライアントアップデートで、Linuxにおける一般的なクラッシュを修正。このうち最も大きな影響があったのは、setenv と getenv 関数の使用方法の変更。

  • 問題点: setenv はLinuxで安全ではないAPIであり、マルチスレッド環境で使用すると問題が発生する可能性がある。getenv 呼び出し後に、別スレッドで SIGABRT のようなクラッシュが発生することがある。

  • 解決策:

    • ほとんどの setenv 呼び出しを削除し、プロセス生成時に execvpe を使って環境を渡すようにリファクタリング。
    • getenv への依存を減らすため、呼び出しをキャッシュ。
    • 残っている setenv の使用例については、「環境マネージャー」を導入し、起動時に十分に大きな値バッファをあらかじめ割り当て。

  • 結果: これらの変更により、SIGABRT の発生頻度は大幅に減少。ただし完全な解決策ではなく、外部ライブラリが setenv を呼び出す場合は依然としてクラッシュのリスクがある。

  • 今後の計画: glibc では、この問題を解決するために、非同期シグナル安全性を維持しつつ envp の使用と同期する方法を研究中。この作業は複雑だが、長期的には POSIX 仕様から逸脱しない範囲で解決策を提案する予定。

関連記事

1件のコメント

 
GN⁺ 2024-11-12
Hacker Newsの意見

  • Red Hatのグラフィックスタックの安定性問題により、パッチが検討中

    • getenv のスレッド安全性修正が glibc 2.41 に含まれる可能性が高い
    • setenv はすでに環境文字列を解放しないため、対処しやすい
    • unsetenv は並行性の問題があるため複雑
    • getenv にロックを導入したくない理由は、非同期シグナル安全性を維持するため
    • vfork+execve のため、メモリリークを避けるのが難しく、環境処理の修正には議論がある

  • Linux で Steam がうまく動作していることに感謝している

  • 環境変数は起動時に読み込み、setenv を使わないのが最善の方法

    • 新しいプロセスを生成するときは、現在の環境を複製して新しい値を更新する必要がある
    • getenv/setenv を IPC メッセージング機構として使うのは問題になる可能性がある

  • setenv が Linux API なのかという疑問がある

    • setenv は POSIX で定義されており、Linux カーネルではなくユーザー空間で実装されている

  • プログラムがあるスレッドで setenv を呼び出し、別のスレッドでその効果を必要とする場合があるのかという疑問がある

    • GLIBC は危険な関数をよく文書化しているため、ロックやコピーを追加できる

  • Steam が接続がないと文句を言う問題がある

    • 「再試行」ボタンを何度も押すと動作するが、不便

  • Steam クライアントと Linux プログラミングに関する洞察が興味深い

    • リリースノートが詳しくない理由は理解できるが、「一般的なクラッシュ修正」は控えめすぎる表現

  • glibc で問題を解決するには、機能面でのトレードオフが必要になるかもしれない

    • 長期的に合理的な提案ができるなら、追求する価値がある

  • Steam クライアントのレンダリング性能は、マウスがウィンドウ内にあるとき良くない

  • Linux 版 Steam クライアントには長年続いているバグがある

    • 1日以上 Steam を起動したままにすると、ウィンドウハンドルが不足して新しいグラフィックアプリケーションやウィンドウを開けなくなる
    • Steam Chat を使うと問題がより早く発生する
    • この問題は GitHub に記録されているが、理由もなくクローズされた
    • 個人的には毎日 Steam を再起動している
    • KDE/Wayland と X11 でもこの問題を確認している