Ruby Kaigi 2016 3日間を終えて 〜pid2line.rbについて〜

 非常に素晴らしい3日間でした。Rubyがどう作られているのかという低レイヤの話から、Rubyを使って楽しいものを作った話まで、色々な話がたっぷり聴けてよかったです。

 で、1日目の感想みたいにふわっとした感想を書くのもいいのですが、最終日の最終講演がよくわからなかったので、ちょっと自分で食いついて話を聞いたところを書こうと思います。

togetter.com

で紹介されていたpid2line.rbについての話です。食いついて話を聞いた相手は @shyouhei です。

pid2line.rbとは何なのか

 すごく便利なデバッグツール。

pid2line.rbが有用な場面

 プログラムの動きが妙に遅い、固まってしまった、こういう場合はバックトレースも出てこないし、デバッガのブレークポイントをどこに仕掛けたらいいのかも難しい。こういう手がかりが超少ない場面で有効。

pid2line.rbは何をするのか

 今固まっているプログラムがどこのメモリアドレスを参照しているのかを見て、どこのメモリの中に入っている関数で動きが止まっているのかを調べる。

 どうやるのかというと、まず、固まっているプログラムが今どのメモリを参照しているのかをOSに訊きに行く。

 そのメモリの番地がわかったら、どの関数がどこのメモリに入っているかを保存してある『マップ』という領域を見に行き、こけている関数を調べる。

 さらにその関数の中のどの命令で止まっているのかを、関数が入っているメモリを頭から調べていくことで特定する。

 あとはそこでこけている原因を考えるだけ!

FAQ

Q:OS Xだと使えないというのはなぜ?

A:OS XにはLinuxに存在するprocfsという機能がないから。procfsはどのプロセスがどんなライブラリをロードしてるのかとかどこのアドレスにあるのかとかが分かる便利機能。/procfsを見に行くと、pidが名前になってるディレクトリがずらっとあってその中のファイルを見ればいい。

Q:そのprocfs、悪用されたりしないんでしょうか?

A:他人のプロセスを見に行くのは難しいし、自分のプロセスであってもメモリを読むのと書くのは別問題なので、そんな超危険ってわけではない。

Q:バックトレースも出ずにプロセスが突然死ぬバグにも対応できますか?

A:そのパターンには対応できないと思う。

 

というお話でした。質問に答えてくれた @shyouhei に感謝!です。

 そして、この素晴らしいKaigiを作ってくれたスタッフの皆様やスポンサーの皆様、参加者の皆様、ありがとうございました!