Debug Hacks Conference 2009
Debug祭りに参加してきた。
1. 本ネタ
憧れのオライリー本を書くということでオライリーメーカーを使ったら消せなくなっちゃった。
straceを使ったデバッグ。ログが大量に出るが、先頭のほうは無視してよく、後ろから見て行ってエラーになっている部分から探すのが手っ取り早い。
次の本の準備中。（消費電力関係？）
2. 本に載らなかったネタ
あるファイルはどのプログラムが吐いているのかを調べたりするときに、rpmコマンドがけっこう使える。rpm -qfであたりをつけてrpm -qlで探したり。その他のファイルアクセスにはstraceが使える。
シェルスクリプトをデバッグするときはbash -xとか。
SysRqネタを書いている途中でカーネルのバグに気づきパッチを送付したらakpm氏がマージしてくれた。（かっこいい！）
3. GDBのデバッグスクリプト
GDBはユーザー定義コマンドで構造体表示コマンドとかが作れる。（カーネルのスケジューラの構造体とか、定番の構造体を見るのに便利そう）
Cで構造体表示関数を作ってLD_PRELOADで読み込ませるというhackもある。LD_PRELOAD=./mylib.so gdb ./sampleとか。
4. malloc/free
glibcはMALLOC_CHECK_で二重開放とかのチェックができる。（Windowsでいうと_CrtSetDbgFlagとかその辺か）
カーネルでメモリリークとかを知りたい場合はデバッグオプションがあるらしい（kmemleak?）
5. Debug Hacks Hacks
デバッグの原則いろいろ
- 手順をワークフロー化する
- 疑えるものは全て疑う（電源入ってるか etc）
- 何かを交換するときは一つずつ
- 予備系を用意して同じデータを食わせてみる
- 目的のために「適切であれば」手段を選ばない
6. little debugging principles
バグとの戦いを避ける話。
デバッグは属人的になりがちなのでノウハウを共有したほうがよい。
デバッグプロセスとしては再現-特定-修正だが、特定ができれば修正は簡単であることが多い。
簡単に再現させるためにはログが重要。
簡単に特定するにはBDD（behavior driven development）でやるとよい。仕様をしっかり書いて仕様を満たすための最小限のコードを書けば、仕様を満たさない部分がバグなので特定も簡単。
legacy code（テストがないコード）が問題。不要なら削除するし、必要ならコードを見て仕様とテストを書く。
Design by Contractでやる方法。assertをいっぱい埋め込む。
原因が不明な場合はデータ中心でトレースする。何が起きているか→どこで壊しているかという順序で見る。
マクロだらけのコードをデバッグするときは、部分的にundefしたり。（undefして関数化するってことか？）
番外編
表紙が蚊遣り豚なのはなぜ？→虫をとるから。フィーリングで。
本の感想
Debug Hacks Hacksのプレゼンには、もしDebug Hacksをデバッグ入門書にするのなら入っているべき項目がだいたい網羅されていた。逆に言うとこの部分がないために、Debug Hacksは入門書ではない。また、PC向けのLinux kernelが中心でターゲットが非常に狭い。
なのでデバッグ全般に関する実用書としては疑問だが、普通は外に出ることがないデバッグの現場を書籍化したという点で記念碑的な一冊と言えると思う。
サイン会が始まる前にサインしてもらったため、たぶんサイン本第一号。
