メモリダンプと模様が見える男

10年以上前の昔話であり、そんなこともあったのねという話。あるいはエンタープライズサポートってそんなことやってるのねという話。

カーネルメモリダンプ

Linuxカーネルをエンタープライズに使おうとした企業、富士通やIBM、日立といった企業がこぞってカーネルに入れようとした機能がカーネルがパニックした時に「なぜコケたのか」調べるための機能であった。その最たるものがメモリダンプだった。この機能はカーネルパニックが起きた後のメモリをディスクに吐き出す。この吐き出されたメモリイメージをダンプと呼び、これをデバッガに食わせて原因調査をする。

カーネルデベロッパはパニックが起きたら再現条件を探して理詰めでバグを探すのが得意だが、顧客先でパニックが起きたら「再現させてくれ」とは中々言えないのでこの機能はサポートには重要だった。そして、ダンプ調査の技を持つエンジニアも居た。

地雷型メモリ破壊パニック

色々と調査が難しいバグがあるが面倒なものの一つのはメモリ破壊系である。何処かのスレッドがメモリを破壊し、後から他のスレッドが破壊されたメモリを参照してパニックする。壊した後に読みに行かないとパニックしないので原因発生から数時間後にパニックするなんてこともある。

中途入社で会社に入って４年目ぐらいのある日、今日もまたダンプがサポートに回ってきた。コケている箇所は簡単にわかったが、参照しているメモリの中身が何者かに破壊されていたのが原因。私は「こりゃダメだ、わからん」となった。16進数の羅列が延々見えるだけなんである。

模様が見える男

当時のチームのリーダーは「模様が見える」とされるエンジニアだった。この時までその真の意味を理解していなかったが...

私が匙を投げかけてしばらくすると、壊された内容をリーダーが解析した。曰く「壊されているのはページの先頭32バイトの一部のようである」「 壊しているデータを解析すると、task構造体とmm_struct構造体へのポインタのようだ」「この２種類のポインタが並んでいるのはtask構造体しかない」「何処かのコードでtask構造体をコピーしようとしてメモリを破壊している」

こういう解析をダンプを目で見てやっちゃうのが「模様が見える」ということであった。なかなかここまで追い込めない。結果的に特定条件で/proc配下の特定のファイルを読んだ時にtask構造体の中身をバッファにコピーしようとし、その際にバッファ溢れすることがわかった。ここまで１日くらい。

パニックのトリガー条件がわかったのでSEに伝えて回避してもらい、後からパッチを提供した。もちろんパッチはコミュニティに還元している。

書いてみるとあっさりしているが泣きたくなるような酷いダンプだったしそれを解析しちゃう人がいるのは驚きだった。機能があるから人がいるのか、人がいるから機能があるのか。私はダンプを使いこなしたとは言えない。

世の中にはネットワークというダンプも取れない（再現させてトレースするしかない）世界もあるので上には上があるんだろうけども。