世界を動かす技術を、日本語で。
5つのパートからなるスレッドで、彼らは「今や100%確信している」と言ってるけど、ビットフリップをどうやって検出してるのか、ただ「メモリを分析している」以外は一言も触れてないのが気になる。
昨年、ブラウザがクラッシュした後にユーザーのマシンで動作する実際のメモリテスターを導入しました。彼は何も説明していないけど、おそらくそのコードはどこかにあるんじゃないかな。
これを最も簡単に行う方法は、memtest86などがやっていることだと思うけど、メモリの領域に固定パターンを書き込んで、後で読み返して変わっていないか確認することだよね。それから、以前書き込んだビットを反転させる必要があるパターンを書き込んでいく。こういうことは[1]がメモリが壊れたことを教えてくれるし、もし非自明な（例えば、多くのビットが高低）マジックナンバーがあって、1ビットだけが間違っている場合、それはランダムな上書きではない可能性が高い - [2]の例を見てみて。さらに、[3]では、人気のあるドメインの単一ビットの違いを調べた実験の面白い例がある。編集: 最後に、Mozillaのソースを掘り下げてみたら、クラッシュ時にテスターとして使われているのは[4]だと思う。
彼らはクラッシュがビットフリップから来ているとは知らないみたいだけど、そのクラッシュはフラッキーなメモリを持つ人たちから来ている可能性があるってこと？
よくあるケースは、未割り当てのアドレス空間を指すポインタがセグフォルトを引き起こすこと。ポインタを見てみると、1ビット以外は有効だってわかる。
誰かがこれに関するデータを集めているのを見ると嬉しい。メモリの問題って、コンピュータ全般で最も過小評価されている問題の一つだと思うから、もっと詳しいレポートが見たいな。短いホワイトペーパーみたいなのがあればいいのに。
とても興味深い。Goのツールチェーンには（デフォルトではオフの）テレメトリシステムがあるんだ。Go 1.23では、runtime.SetCrashOutput関数を追加して、実行中のゴルーチンのクラッシュに関するスタックトレースを含むフィールドレポートを集めるのに使った。goplsでそれを有効にしてから1年以上経つけど、何百ものバグを発見したよ。テレメトリを有効にしているユーザーは約1000人に1人だけだけど、それでもクラッシュに関する貴重な情報源になっている。ほとんどの場合、問題を再現するテストケースを簡単に再構築できて、バグは1時間以内に修正される。こうやって何十ものバグを修正してきた。原因が明らかでない場合は、if文やアサーションを追加してクラッシュを「洗練」させて、次のリリース後にスタックトレースから実行状態に関する追加情報を得るようにしている。ただ、説明できないフィールドレポートがいつも残っていて、壊れたスタックポインタや、壊れたgレジスタ（現在のゴルーチンへのスレッドローカルポインタ）、nilチェックを通過したポインタをデリファレンスしてパニックになることがあった。これらはすべてメモリの破損を示している。理論的には、unsafeを乱用したりデータレースがあれば何でも起こり得るけど、実行可能ファイル内のunsafeの使用をすべて監査した結果、安全だと確信している。データレースの不在を証明するのは難しいけど、通常はどの変数が壊れるかに何らかの局所性が見られるが、ここではそうではなかった。場合によっては、メモリ以外の命令（例えば、MOV ZR, R1）でクラッシュが発生することもあって、これは誤実行を示唆している。CPUの故障か、テレメトリの記録のバグかもしれない。プログラマーとして、自分のコードのミスをコンパイラやランタイムのせいにしてしまったことが何度もあったから、今回は基盤を疑う自信を持つまでに時間がかかった。でも最近、ちょっと計算してみたら（https://github.com/golang/go/issues/71425#issuecomment-39685...）、説明できないフィールドレポートが驚くほど多いこと、つまり週に約10件がユーザーの間で発生していることは、故障したハードウェアの範囲内に収まると結論付けた。特に、ユーザーの大半がラップトップを使っていて、パリティメモリがないからね。確定的な確認が欲しいけど、Firefoxチームがクラッシュ報告ソフトウェアでメモリに対してどんなテストを行っているのか気になる。
僕は、クラッシュに焦点を当てたもっと分析やテレメトリーを生産環境で進めようと上司を押してるんだ。シェアしてくれてありがとう！
場合によっては、非メモリ命令（例えば、MOV ZR, R1）でクラッシュが発生することも見られます。これは、誤実行を示唆していますね。CPUの故障か、テレメトリの記録にバグがあるのかもしれません。要するに、ビットの反転はメモリに常駐しているすべてに影響を与えます。プログラムコードも含まれます。実行中の行がMOVに対応しているとされるとき、実際にどの命令が読み取られたのかはわかりません。正当なメモリ操作だったかもしれませんが、計測が間違ったオフセットを報告している可能性もあります。回避策はいくつかありますが、一般的に言えば、システムがプロセッサのキャッシュより大きなプログラムを実行し、ビット反転が発生する可能性がある場合、出力は無意味です。使用しているテレメトリも含めてね（なぜなら、それはRAMから実行されるコードで、RAMにアクセスするからです）。
この話は以前HNでもしたことがあるけど、ArenaNetのビジネスパートナーであるマイク・オブライエン（battle.netの創設者）が、2004年頃にGuild Warsでビットフリップを検出するシステムを作ったんだ。ゲームクライアントから意味不明なバグ報告が定期的に来ていたから、バグトリアージプロセスの一環としてね。Guild Warsは毎フレーム（約60FPS）ランダムなメモリを割り当てて、計算を行い、結果を既知の値のテーブルと比較していた。約1000台に1台がこのテストに失敗してた！テスト結果はレジストリに保存して、自動バグ報告に含めていた。問題の一般的な原因として発見したのは、- オーバークロックされたCPU - 悪いメモリ待機状態の設定 - 電源不足 - 冷却ファンがスペック不足または埃で詰まっていることによる過熱 これらの問題は、Guild Warsが屋外の地形をレンダリングしていたため、当時の他の3Dゲームに比べて多くのポリゴンを処理していたから起こったんだ（バイナリ空間分割やポータルを使って屋外のものにはあまりうまく機能しない）。だから、ゲームがコンピュータを熱くさせていた。数年後、Dellのコンピュータが合理的な範囲を超えたアナログ部品の問題を抱えていることを知った。Dellはコンピュータ用に最も安い部品を調達していたから、これも原因だと思う。そしてさらに数年後、メモリに対するRowHammer攻撃について知った。これも別の原因だったかもしれない。私たちが使っていた数学計算は、メモリの行に頻繁にアクセスするように設計されていたからね。時々、コンピュータが動作すること自体に驚かされるよ！ちなみに、私がこの件に貢献したのは、テスト失敗時にブラウザを起動するコードを書いて、プレイヤーに埃を掃除するように伝えるウェブページを表示させることだった。
ここで創設者の一人からGWの話を聞けるとは思わなかった - ありがとう！
有名なレイモンド・チェンの投稿があって、ブルースクリーンの死の報告の中で、結構な割合がオーバークロックによるものだったって話があるんだよね。中には、自分が買ったパソコンに騙されたことに気づいていないユーザーもいたみたい。ほんと、イライラしただろうな。