Debug Hacks Night

まいどまいどでございますが、2009/05/28 に、

Debug Hacks -デバッグを極めるテクニック&ツール

の出版記念イベントの最後を飾る「Debug Hacks Night」が、著者陣のみなさまが籍を置かれる MIRACLE LINUX さんで行われましたのでいそいそと参加してきました。

無粋なことを書きますが、私は別に著者陣の皆様に過度に思い入れているつもりもないですし、別にオライリー・ジャパンさんの宣伝をするつもりもありません。
でもこの本のコンセプトを聞いたときに絶対面白い！　と思ってジュンク堂イベントにも参加してその場で現物を入手して、読み通したら想像以上に面白かったので、こうやってイベントに参加してその内容をしこしこブログにしたためようと思っている次第でございます。

とはいえ睡眠不足でふらふらなので今日は謝辞のみ。

まずは Debug Hacks という素敵な本を世に送り出していただいた著者陣とコントリビュータの皆様、
とりわけ本日のスピーカーの id:hyoshiok こと吉岡さんと吉田さん、
この本を出版し、またバッヂを大量に寄贈いただきイベントの盛り上げに一役買っていただいたオライリー・ジャパン様、
素敵なイベントを主催いただいた MIRACLE LINUX 様に深く感謝したく思います。

hyoshiok さんの GDB 講座などなど

えーと内容は Debug Hacks と被るので読め！　ってとこなんですが、

ブレークポイントを適当なところに仕掛けて、そこまで期待通りの結果が得られていればその前は OK ということになり、そうでなければその前にバグがあるということになる

というのはちょっと新鮮でした。
オイラの場合は関数の頭を起点に見ていくことが多いので（つまり関数先頭にブレークポイントを設置するということ）。
まあ二次元で見るか、奥行き（コールスタック）で見ていくかの違いなのかもしれないけどね。

あと当たり前の話だけど心に響いたのは：

市場で起きた問題に関して問題の再現（環境設定・ヒアリングなど）を行うのは非常にコストが高い。一方でテストはそのコストが安い。だからなるべくテストでバグを検出しておくべきだ

という一節。

まだまだ書きたいことはあるのですが私のブログはいつも長くて焦点が甘いと評判なのでこの辺で。

感想、Q&A など

C

大急ぎで読んできただけだが、バグを追いかける過程が非常に面白く、推理小説を読むような楽しさを感じることができた*1。一方で、例えばある現象が起きたときに、それがどのプロセス、モジュールで問題が起きているか、そういったことを、多分みなさん Linux に習熟されているから自然とわかってしまうのだと思うが、そこが私だとちょっと難しいので、そこの間を埋めるブログなりなんなりを紹介していただけるとうれしい。

Q

私はWebアプリ屋で周囲にもそういうエンジニアしかおらず、本書にあるようなアセンブリレベルでデバッグしていくといったローレベルのことをやろうとする人間は少ない。どうやればそういう若いエンジニアに低レベルに目を向けさせられるだろうか。

A

それは単純に、低レベル楽しいよ、ってことを如何に伝えることかと思う。楽しいと思えば自然とやるから。

よしださん　ボツネタ Vol. 1.1 *2

今回はデバッグということで次のようなことはボツとなってしまった。

• Trouble Shooting
• Log
• 開発環境
• ボトルネック分析
• OS インストール・起動障害

printf Debug

• デバッガが使えない場合 (デバッガ自体のデバッグ) では有効
• 欠点：どうしても Debug 版と Retail 版の二重管理となる
• 没になった最大の理由：hyoshiok 哲学に反する

各種トレース系ツール類、gdb 以外のデバッガ

• 特に kgdb や KDB は取り上げたかったが、著者側のノウハウがなく断念

Trouble Shooting

• ログ解析
  • syslog
  • sysstat
  • mcinfo
• パケット調査
  • ethereal
  • wireshark
  • tcpdump

開発環境 *3

• gdb + emacs
• gcc 拡張 (これを知らないとカーネルのソースを読めないので)
• シンボルのストリップ
• Cscope
• lxr: the Linux Cross Reference
• git
  • git bisect *4
  • git + emacs
  • gitGUI
• 高速コンパイル *5
  • コンパイル結果のキャッシング
  • 分散コンパイル

ボトルネック分析

• sar*6, iostat, top, vmstat
• /proc/meminfo
• ベンチマークの選択

チューニング

• sysctrl
  • memory
  • disk
  • N/W

Test

• gdb で変数書き換えをうまくつかってテストカバレッジをあげる
  • さらにマクロでそれを自動化

上記以外にも MIRACLE LINUX さん取り扱い商品でフォールトトレラントなサーバ運用をするような説明がありましたが、Debug Hacks という点ではちょっとずれるので割愛。

ビアバッシュ

相変わらずいろんな人といろんな話をしたなぁ。
でも今回は主に編集さんと話していたような覚えがある。
とっても面白い本に仕上がっていてうれしかったですって話とか、印刷の話とか、他のオライリーの書籍の話とか。

それから hyoshiok さんに d:id:naruoga:20090528:1243491493 みたいなことやってますって話をしたら「ぜひブログに書いてください」ってはっぱをかけられました。来週の小江戸オフには形にして持っていきたいと思います。

あと Kwappa さん がじゃんけん大会でＴシャツをゲットしてました。おめでとうございます！

いやいやしかし、本も楽しかったしイベントも楽しかった。
あとはこの知見をこれからどれだけ生かせるかですな。頑張りましょう。

*1:お分かりかと思いますがこれ私のコメントです。けっこう気に入っていただいた言葉のようで、オライリー・ジャパンの担当編集さんに「読者の声として使わせていただいていいですか？」と言われたので「もちろん」と答えたけど、さてどうなりますやら。

*2:多分 Debug Hacks Conference のときが 1.0 だったんでしょう。

*3:まあ、gdb も開発環境といえばそうだけど。

*4:ご存知、二分探索でバグが混入したコミットを見つける方法。でも手間がかかる割に違う答えが出てしまうこともあるので反対派もいる……らしいです。

*5:先の git bisect のように何度もコンパイルを繰り返す際に有効。

*6:字が汚くて見えないけど違うかも……。