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の話を聞けるとは思わなかった - ありがとう！

有名なレイモンド・チェンの投稿があって、ブルースクリーンの死の報告の中で、結構な割合がオーバークロックによるものだったって話があるんだよね。中には、自分が買ったパソコンに騙されたことに気づいていないユーザーもいたみたい。ほんと、イライラしただろうな。

高価なコンテンツのために冗長な割り当てや、まだ重要だけど低価値な資産のためのハッシュチェックを考えたことはある？ゲームのメモリ消費の大部分はメディア資産だと思うんだけど、もしそれが壊れたら大問題だよね。重要なコンテンツのストレージ要件は、かなり無視できるレベルだと思うんだけど。

>時々、コンピュータがちゃんと動いてることに驚くよ！これ言うの面白いね。しばらくOCしたRAMを使ってたけど、全然不安定さは感じなかった。でも、イベントビューアーはひどいことになってた。速度を少し下げたら（確か3800MHzから3600MHzに）そのエントリーが止まったよ。

AMDのスレッドリッパー1950xとECCメモリで動くASRockのマザーボードのおかげで、オーバークロックを学んだんだ。いくつかのタイミングを見つけたら、通常のテストを数日間パスできたけど、それでも月に数回は修正されたエラーを見かけたから、本当の安定性を求めるなら引き下がらなきゃいけなかった。ECCがなかったら、珍しいクラッシュをソフトウェアのせいにしてたかもしれない。それ以降、ECCメモリをオーバークロックすべきじゃないと思ってる人はちょっと混乱してるなって感じるようになった。オーバークロックすべき唯一のメモリだから、エラーがないことを証明できるのはこれだけだし。DDR3とDDR4メモリ（少なくともAMDシステムでは）は、標準のJEDECタイミングよりもかなりの「パフォーマンス」があったよ。（パフォーマンスは相対的なもので、実際には得られるパフォーマンスはほとんどのことにとっては大した利点じゃない好奇心のようなものだし、安定性のギリギリのところでは高いタイミングが逆にパフォーマンスを悪化させることもある。）DDR5について気づいたのは、本当の安定性を得るのがずっと難しいってこと。CPUの取り付け圧が高すぎたり低すぎたりするだけで、間欠的な問題やエラーが出ることもある。非ECCのDDR5をオーバークロックすることは絶対にないし、信頼できないから、余裕も前の世代よりずっと少ない。熱にも敏感で、50〜60度Cの間で問題が出始めるし、オーバークロックする時は専用のエアフローが必要だよ。ちなみに、オンチップECCのことを言ってるわけじゃない、それは重要だけど、フルクラシックECCとは実際には違うから。メモリエラーのせいでソフトウェアのデバッグに無駄な努力がかかることを考えると、嫌になるね。

そうそう！これ、10年前に読んだことある… https://www.codeofhonor.com/blog/whose-bug-is-this-anyway

GW1は僕の子供時代そのものだった。月額料金のないMMOは母親に受けて、友達とも何年も会えた。8スキルビルドシステムは天才的だったし、プレイヤーキャラクターが登場するカットシーンも良かった。もし3作目が出るなら、ビルド作成を通じてもっと表現できるものが見たいな。ただ、バランスを取るのが難しいのは分かるけど。

> つまり、Firefoxユーザーが見るクラッシュのうち、最大10%はソフトウェアのバグじゃなくて、ハードウェアの欠陥が原因なんだって！大胆な主張だね。直感的にこれは間違ってる気がする。クロミウムベースのブラウザ、例えばトリウムを使ってると、そんなにクラッシュしないし。

クラッシュの10%が必ずしも君のクラッシュの10%を意味するわけじゃないよ。

君の直感が外れてるかも？僕もFirefoxはChromeベースのブラウザよりクラッシュが多いと思うけど、Chromeの安定性が他の90%のクラッシュをうまく処理してる可能性が高いよね。もしChromeのクラッシュの50%がビットフリップによるもので、ビットフリップが両方のブラウザにほぼ同じ率で影響を与えているなら、ChromeはFirefoxの1/5のクラッシュしか経験してないってことになる… たとえビットフリップによるクラッシュが両方のブラウザで同じ率で起こってもね。もしハードウェアの不具合によるクラッシュが実際にはもっと多かったら、Firefoxにとっては良いニュースだったのに！この数字は、Firefoxのクラッシュの大半が実際にはバグのあるソフトウェアから来てることを示してるよ : (

彼はそのことについてスレッドで触れてるよ。

もしかしたら、Firefoxのタブがそんなにメモリを食わなければ、0.005%だけで済むかもね！

>大胆な主張だね。直感的に言うと、これは間違ってると思う。RAMのフリップはよくあることだから。この手の問題は昔からあって、たぶん悪化してる。IBMもこのデータ持ってたし、DECも持ってた。AmazonやGoogle、Microsoftもほぼ間違いなくデータを持ってる。コンピュータのフリートを運営してる人はみんなデータを得るし、その一般性にはいつも驚かされる。ZFSはRAMのフリップを見つけるのが得意だよ。

みんなそんなにFirefoxのクラッシュが多いの？私のはめったにクラッシュしないよ。数週間ずっとタブを開いたり閉じたりしながら動かしてるけど。

つまり、何も関連付けられないクラッシュが結構あったんだ。ハードウェアの問題も、他の何かと同じくらい良い説明になるよ。

> 大胆な主張ですね。僕も同意します。彼がその主張を何の証拠も理論的な議論もなしに裏付けていないのは良いことですね。さもなければ、あなたは大馬鹿者に見えるでしょう！

彼らは、もしあなたのコンピュータにハードウェアの不具合があれば、テレメトリシステムに多くの追加クラッシュを送信している可能性が高いと主張していると思います。あなたのハードウェアは正常に動作しているかもしれませんが、隣の人は30%も多くのクラッシュを送信しているかもしれません。

>> 言い換えれば、Firefoxユーザーが見るすべてのクラッシュの最大10%はソフトウェアのバグではなく、ハードウェアの欠陥によるものです！ > 大胆な主張ですね。直感的にこれは間違っていると思います。クロミウムベースのブラウザ（例えば、Thorium）を使っているときは、同じ量のクラッシュは発生しないように感じます。それは誤解です。調査結果はクラッシュの構成に関するもので、全体のクラッシュ率ではありません。極端に言えば、Firefoxの歴史の中で10回のクラッシュがあり、そのうち1回がハードウェアの故障によるものであれば、その結果は依然として正しいのです。

DDR4とDDR5のビットフリップを見てみたいな。私の理解では、DDR5には何らかのECCが必要なんだよね。[1]

Corsairからの情報ですが、>> DDR5技術には、メモリセルの信頼性を向上させ、メモリメーカーの収率を増加させるための独自のデータチェック機能が搭載されています。ただし、これが完全なECCメモリになるわけではありません。「正しい」ECCは、より広いメモリバスを持っていて、CPUがチェックサムビットを発信し、それがメモリの各ワードと一緒に保存され、メモリを読み取るときに再度CPUによってチェックされます。例えば、64ビットのマシンは実際には72ビットのメモリを持つことになります。DDR5の「ECC」は、メモリスティック内でのみエラー訂正を行います。エラー率を減少させるために存在していて、そうでなければ受け入れられないメモリが使えるようになります。個々のセルが小さくなりすぎて、自分自身ではもはや信頼性が十分ではないからです！

DDR5は、収率を向上させるためにECCでパッチ処理された限界DRAMを搭載しています。これは完全に信頼できるRAMとは異なります。

それだけ高いと、システムソフトウェアの問題が混ざってるんじゃないかって思う。mallocやページテーブル管理のレアなレースみたいな。

ECCは1GBを超えた頃には標準になってるべきだったよ。ECCメモリが手に入りにくくて高いのは本当にイライラするけど、無駄なLEDがついたメモリは安いからね。

ECCの価格や入手可能性がそんなに気になるわけじゃなくて、ECCをサポートするCPUやマザーボードを手に入れるのがサーバー以外では簡単じゃないのが問題なんだ。消費者向けのエコシステム全体がちょっとひどいよ。少なくともAMDは消費者向けのCPUでもECCを使えるようにしてるけど、Intelはプロシューマーやワークステーション向けのものだけがECCを持ってるからね。

ECCは伝統的に遅くて、かなり複雑だし、問題を完全には排除できない（ほとんどのメモリは1ワードあたり1ビットを修正して、2ビットを検出する）。環境要因、例えば不安定な電源や温度、RF干渉が簡単に排除できるサーバールームのような場所では意味があるけど、そうだね、ECCは99%のケースを解決するから、君に同意するよ。

知らない人のために言うと、これに関してはIntelが悪いんだ。

反対票が来るかもしれないけど、これはちょっとおかしいと思う。ビットフリップは頻繁に起こるけど（ECCは改善にはなるけど、問題を完全に解決するわけじゃない）、そんなに頻繁ではないよね。テレメトリーを有効にしてるユーザーが変わり者で不安定なハードウェアを使ってると考えるか、実際にはビットフリップを検出できてない（メッセージが示すように）か、いろんな問題があるかのどれかだと思う。特定の構造体が間違って処理されたり、パースされたり、保存されたりする確率が1/10だと、画像編集からCADまで、いろんなシナリオでかなり深刻な影響が出るよ。しかも、不安定なハードウェアのビットフリップは保護リングを選ばないから、OSのルーチン、デバイスへの読み書きやメモリに触れるすべてに影響が出る。そう、故障したRAMシステムをたくさん見てきたよ（多くのWinMEのクラッシュは、実際にはW98で問題なく動く不良RAMスティックが原因だった）。ブラウザやアプリを選ぶわけじゃないからね。

クラッシュの10%って書いてあるけど、Firefox自体がそんなにバグが少なくて滅多にクラッシュしないなら、君の言ってることと矛盾しないよね。私の「Hello World」スクリプトのクラッシュの99%がビットフリップによるものでも驚かないよ。

言い忘れたけど、はい、Firefoxのインスタンスは100%クラッシュすると思ってるよ。長時間動かすとね。私は（今でも）Firefoxをセカンドブラウザとして使ってる。

これは、15年前のマシンを使ってる3人のユーザーが大きく偏らせるような指標に見える。正規化して、外れ値を一貫した方法で排除する必要があるね。