「Debug Hacks」の発売記念イベントでもある、Debug Hacks Conference 2009に行ってきた。 著者の一人である@hyoshiokさん曰く「今後も、デバッグについて語り合える場が続いていけばいいなと思っています」と。 それゆえの2009なわけですね。
ValgrindとかGDBとか大して使いこなせてない身なので、「Debug Hacks」に興味はあったのです。購入ついでにお話を聞いてみようと思ったんだお。
会場で買うと、白地の蚊取り豚Tシャツもらえた！やったね！
当日のメモり。
■大和さん ・デバッグ本を書きたかった。 ・オライリーメーカー ・strace システムコールを追うよ ・最後から見る ・-iつける アドレス表示 ・GDBで調査。アドレスでブレイクポイント。 質問： アドレスがランダマイズされる時は使えない。 ■大岩さん ・RPMコマンドによるデバッグ ・/var/spool/clientmqueue/にファイルがどんどん溜まる ・よくわからん ・こういうときはrpmコマンド ・rpm -qf /var/spool/clientmqueue/ sendmail hogehoge ・fromにlogwatch ・rpm -ql logwatch | grep etc ・lsでファイル日付チェック 4ファイル1日置き ・/etc/crontab ・ファイルを調べるにはrpm どのファイルを読み込んでいるかわからないときはstrace ・ ・スクリプトのデバッグ ■安部さん ・print派です ・GDB ・ユーザ定義コマンドを利用するとちょっと楽になる ・リストを全部ダンプするのもがんばればおk ・debuginfo付きバイナリのシンボル情報だけ利用 ・デバッグ関数を追加する ・共有ライブラリにして、ターゲットにロードLD_PRELOAD ・踏み外した ■島本さん ・ライブラリ関数で落ちる ・二重開放とかあるある ・Valgrind ・glibcのMALLOC_CHECK_ ■吉田さん ・Debug Hacks Hack ・問題の切り分け ・トラブルシューティングHacks ・突然止まる ・相関関係と因果関係は違う ・保存する必要ある？ メッセージの保存？ ログは？ SS？ バグ報告に十分？ ・真の目的は？替わりの方法はない？ ・期限 明確な期限○ ・最悪のケースって？ お金？時間？名誉？ ・想定した上で考えよう。 ・ストップロス ・マイナスな言葉にしない。いい言葉。挑戦・チャンス ・再現性＆再現手順、別環境は？ ・エラーメッセージは？ 英語もちゃんとね。 ・事例を検索 ・誰がやるの？ ・自分より効率のいい人、団体など ・誰かに聞く ・責任と期限が決まったら行動 ・一度に一つ ・バックアップ ・クリーン環境と実環境 ■Yuguiさん ・とにかく共有しよう ・どうやってデバッグしてるの？ あまりしてない。 ・データの流れに注目 ・Userland ・ハードウェアまわりに苦労 ・並列関係（スレッド） ・非同期、シグナル、バイナリまわり ・再現、特定、修正 ・自明にする方法 コード書かない BDD ・仕様への不足、違反 ・テストがない ・削除しちゃう 動けばおk エラーならテストケース行き ・Code Reading ・DbC ・gdb -c ・attach ・二分探索で落ちる範囲を縮める ・根性で試行 ・マクロはundefineして部分的に。 ・ぐちゃぐちゃなとき、丸捨てた。
自分のデバッグは、breakpointやらprint文入れるなりして怪しそうなところをどんどん探していくというごくごく普通なものです。GDB使っても。 勘は働いても、それ以上にいいやり方を知りたいな～という自分にとっては力になりそうな本。 まだ読んでないので、GWに読むつもりでふ。
さて、講演終了後、いがいがさんといがいがさんのお知り合いの方々とお食事会などを('∇') なんというか、Rubyな方々が多いのだぜ。 仕事では、CとかC++とかMFCとかJavaとか某シミュレータとか、短期間で色々とやっているので自分の仕事が○○系とか言えないなーと言葉に詰まったりしました。 まぁ、プライベートでコーディングとか殆どやってないしナ。色々と付いていけないのは当然かー…(´・ω・｀) これについてどうするかは今後の課題でつね。 などと自分自身について思うところはありましたが、色々とお話し出来て楽しかった！ また何かの折によろしくお願いしますです。
余談： FF11プレイヤーは結構いるなぁと思ったｗ しかしながら、まだ同じ鯖の人には遭遇してない。沢山あるから、まぁそれもそうなのだが。
