1 年前、Linux カーネルの開発者は、バージョン 6.2 (およびそれ以降のバージョンの一部) に、明らかな理由もなくブートが約 1,000 回に 1 回クラッシュするバグがあることを発見しました。
しかし、彼らがこの問題を発見したのは、ある Red Hat 開発者 (単独で作業しているにもかかわらず) が、最初に問題を特定するためにマシンの起動と再起動を 300,000 回以上繰り返し、次に問題が適切に特定されたことを確認したためでした。
Richard WM Jones は自身のブログで、 qemuベースの仮想マシンであるnbdkit (クラウド内のディスクへのアクセスを許可するサーバー) を使用して、明白な理由もなくクラッシュが数回発生したことに気付いたため、この困難なタスクに取り組むことにしたと説明しています。彼らは同じ開始点に到達すると常に電話を切りました。
[ 0.070120] SMP 代替メモリの解放: 48K
「誰もこれに気づかなかったのには驚いています」と彼は説明する。しかし、彼はためらうことなく、謎を解くために Git の「bisect」ツールを使用することに決めました。
余談：「二分」とは何ですか？
バグを見つけることはプログラマの日常生活の一部ですが、 Git の多数のコード行やコミット(コードへの変更の組み込み) の中からバグを見つけるのは必ずしも簡単ではありません。幸いなことに、このタスクを簡単にする Git コマンド「git bisect」があります。
これにより、開発者は、安全だと考えられる最新のコミットと、すでにバグがあることがわかっているコミットの間でさまざまなオプションを区切ることができ、バイナリ検索を実行して、その間にあるコミットをより簡単にレビューできるようになります。
続けましょう…
それを承知の上で、ジョーンズの話を続けましょう。二分化に頼れるようにしたい場合は、まずゲストフィッシュツールに頼らなければなりませんでした。「それをループで実行して、『ハング』を収集します。何回ですか? 適切なしきい値として 10,000 ブーツを選択しました。」
「何日もかかった」カーネル バージョンv6.0とv6.4-rc6の間の「痛みを伴う二分化」(つまり、Git の二分化セッション) の後、彼は原因である printk 時間機能の回帰を見つけることができました。
当初は「理由は不明瞭ですが、bisect はコミット マージ」、つまりカーネル コードに同時に組み込まれる多数のコミットの組み合わせを示していました。
「そのため、その中の各コミットを手動でテストする必要があり、さらに 1 日かかりました。」
「しかし、それだけでは十分ではありませんでした。テストするために、失敗したコミットの前 (成功)とその後(1,000 回未満のブートで失敗) にLinux を 292,612 回ブートしました。」
彼の作品は、彼自身のブログと Twitter のコメントの両方で他のユーザーから称賛されました。
それは並外れた探偵仕事です。
粘り強い捜索力に感銘を受けました。私は、1000 回に 1 回の失敗は単なるランダムなエラーによるものだと誤って考えていたでしょう。おめでとう。
このレベルの取り組みは、額に入れられ、スタンディングオベーションの数千人の観衆の前で台座に置かれるに値します。
すべてのヒーローがマントを着ているわけではありません。