Debug Hacks Conference 2009レポ - fslashtのサアラたん日記

　というわけで「DEBUG HACKS」は、広いIIJ大会議室を満席にする140人の参加者で開催されました。
　今回の目玉は著者５人によるデバッグネタについての講演です。
　各自発表５分＋質問タイムと慌ただしいですが、著者の方々の話を直接お聞きできる貴重な機会です。

■ あいさつ
　吉岡さんによる、前書きの朗読

この本に込められた思いが伝わってきます。
なかなかノウハウが共有されづらいデバッグ技法を取り上げ
ミラクルリナックス社内で毎週編集会議を行い作り上げた本がDEBUG HACKS。

■ 前編「DEBUG HACKS著者によるデバッグネタ＊５」

● 大和さん

オライリーメーカーで試しに作ってみた・・・本名で・・・。消し方教えて！

straceを使うと読んでるシステムコールを実行時に表示できるよ。
エラーでおちたら表示されたシステムコールの後ろからみていくとわかりやすい。
strace -i ってオプションつけて実行するとアドレスも表示される。
gdbでエラーのおきたアドレスにブレークポイントを設定して実行するとトレースしやすいのでオススメ

● 大岩さん

本に載せてないネタを用意してきた
【RPMコマンドによるデバッグ】

例） /var/spool/clientmqueue/ にファイルがどんどんたまるのでファイルが作成せれないようにしたい。どれがつくってるかわからないどうすれば？

rpm -qf /var/spool/clientmqueue/
ってやると、つかってるパッケージが表示される
たとえば、sendmail
でも、sendmailは消したよっていわれた
↓
ログをみてみると
メールっぽいファイル
で、fromをみてると　logwatchとなっていた

rom -ql logwatch | grep etc
で、logwatchを含むファイルをぬきだせる
↓
ファイルの日付を見たら定期的に実行されてるぽい
↓
犯人はfronの設定だ (cronのメール送信が悪さしてた）

結論：ファイルをしらべるときにrpmコマンドが便利

【その他】
スクリプトが飛来地得るファイルがわからん
→straceをつかうとどのファイルひらいてるかわかるよ

bashに -x オプションをつけると
スクリプトの実行された行がわかるから便利

Q.会場でプレゼンスライドがなくなてしまったバグはどうやってデバッグするのか？(笑

● 安部さん

GDBでなんでもできるけど使いこなすのは大変
デバッグ対象が複雑なデータ構造なばあいなど
↓
楽にデバッグするには
構造体リストをダンプした場合（最後のメンバが次の構造体へのポインタになってるやつ）
しかもdebuginffoがない
↓
ユーザー定義コマンドを作って使うと便利だよ
↓
「このとおり。」
↓
でもやっぱりdebuginfoのシンボル情報だけでもよめると楽(ptypeコマンドで構造体がよめているのがわかる）
set print pretty on ってかいておくとわかりやすく表示されるヨ

GDBのスクリプトでかくんじゃなくて、Cで書こう
これを今日雄大ぶらりにして LD_PRELOAD でたーデットにロードさせる
↓
すごく便利
※アプリの起動時にしかつかえない
※なのでcore解析にはつかえない

Q.debuginfoが最初からはいってて勉強が楽チンなデストリがほしい。miracleでつくってみては？　→デストリつくってるひとが参加者がまぎれているので頼んでみよう
Q.GDBフロントエンドつかわないのはなぜ？→GUI苦手
Q.なんでHello Wolrdのコードもろくにかけない（著書に書いてある）のにカーネルの世界にはいったのはなぜ？→目の前の落とし穴にまちがえて足をふみはずした

● 島本さん

mallloc()やfree()で障害が起きる場合

free()でおちた
↓
freeの内部関数でsegmentation faultがおきてる
↓
ライブラリでおちるなんてデバッグできない→kernel panicみたいなもの？
↓
なんでライブラリ関すうでおちるの？
↓
でもそれアプリのバグだからちゃんと直そう
・二重開放
・不正アドレス開放

メモリバグ検出ツール（ValGrind）
glibcのMALLOC_CHECK_
をつかうとよい

kernel panicしたらラッキーと思う→ネタが出来た！

Q.kmallocのバグって同じようなことはあるか？→あまり遭遇したことはないが・・・→fault injectionでバグを追っていくといいかも？→カーネルではどうやってデバッグする？（なにかツールはないか？）→slub debug(?)などのオプションでデバッグしやすい・・・？→memory laek debugというカーネルオプションがある。ケースバイケース

● 吉田さん

「debug hacks」を使うには問題を切り分けないといけない
↓
トラブルシューティングHacks

・それまで動いていたものが突然うごかなくなった
↓
なにかかわったところはないか・・・
↓
でも「相関関係 != 因果関係」
↓
トラブルの保存
・ログ
・メッセージの保存
・スクリーンショット（デジカメ）

・心のもちようが大事

【確認事項】
明確な責任

真の目的はなにか
代わりの方法はないか→ほんとにやるひつようあるのか
↓
○　明確な期限
×　できるだけはやく
↓
最悪のケーるとはなにか？人命にかかわるのか？たいしたことないものか？

ストップロス：一致絵のコストで見切りをつけられるか？

「仕様です！」

×　トラブル・問題
といわずに
○　状況・挑戦・チャンス
とよぼう

再現手順は？　別環境でも発生するか？
エラーメッセージはなにか？英語？

Googleなどで事例を検索（エラーメッセージなどから）

だれがやるの？かならずしも自分でやると？→専門家/団体（サポートサービス）も検討
助言をもらえる団体、コミュニティ、同僚はあるか？

【調査】
つかえる手段はなんでも
目的のために「有効ならば」手段を選ばず
※本末を転倒しない

最初に単純で確立の高いものから検討
→電源はいってますか？
→ケーブルは？

システム構成要素をひとつずつチェック
・ハード・カーネル・ドライバ・。設定。アプリ・・・etc
↓
疑わしいものを「ひとつずつ」交換して検証

いったん状況をかえる
・再起動してみるなど

準備しておこう！
データ、システムのバックアップ重要、自動dumpの準備、２重化、予備システム
覚悟（壊れたらどうするか）

実環境とクリーン環境、再現するか。
→クリーン環境で再現したらバグリポートして対応
→クリーン環境で再現しない場合は、徐々に実運用環境に近づけていく（パージョン、設定、データ、OSカーネル、ハードウェアドライバ）など

現象が明確になったら
↓
ほぼ解決
・コミュニティに報告
・ワークアラウンド

ツールとか
いっぱいあるが・・・
最後は、ソースと「DEBUG HACKS」で！

■ 休憩

休憩時間にDEBUG HACKSにサインを頂きました！

わーい。ありがとうございます！家宝にします。

集合

IIJの素敵デバイス「クティオ」

EMobileのモデムを接続するとアクセスポイントになるとうデバイス
CFとUSBタイプ両方がささります。
駆動時間は2時間くらい

IIJのSEIL(ザイル)のペットボトルケースいただきました

nihaさんのカピバラさんとそれ以外のなにか

■ 後編　「講演（Yuguiさん）」(RUBYでの場合）

テーマ
「共有」しよう

みんなのデバッグ技法を公開して共有しよう
というわけで早速自分のやっている方法を・・・

どうやってデバッグしているの？
１．デバッグしない
２．データの流れに注目

対象：
Userland

カーネルにくらべれば高水準で反復可能なので際限度では苦労しない
たいへんだったのは、ハードウェアまわりで１次キャッシュへのノリが悪いとかスレッドとか同期
バイナリまわりでprintfをいれると配置が換わって困る

いまは・・・
Rubyではたいていそんなに苦労しないでデバッグできる
Raildsはバグの再現が比較的容易

デバッグの段階
　再現→特定→修正

再現のためにはログが重要
RailsではWebアプリでエラー発生時に情報（セッションなど）をメールでおくってくれる機能がある。ロギングさえできていれば再現はしやすい。

原因の特定方法
「自明である」という状態にする
↑
コードを書かない
仕様を満たすための最低限のコードのみを書く
「BDD」的なコードで特定可能←再現さえできれば特定は簡単

現実・・・
LegacyCodeがある。←テストがないコード
よくある
↓
コードをみてなぜ必要か考える
↓
仕様記述
↓
それでも不明なコード
↓
削除
→これでも動作する→本当に不要
→エラー→やっぱ必要→テストケースを書く

※あれ？これデバッグ？CodeReading？

「DbC」(Design by Contruct)

Assertをいれていくことで特定できる
デバッグで特定に苦労することじたい敗北である

でも、負けることもある
↓
what(何がおかしいか)を特定→who（だれがおかしくしたのか）を特定

・WHAT
二分探索でデータがおかしくなる場祖を特定していく。
tracerつかう？→OSXで開発しているのでつかってない→いいtracerあったら教えて

・WHO
データの流れを追う。誰が壊しているのか
１．その場で壊している
２．もうちょと複雑→フレームをうえにのぼり引数をチェック
３．ひたすらwatch、条件でブレークとか

データの抽出
・GDBでdegineしていろいろ出力するようにする
・シンボルをデバッガに認識させる rubyではdebug.cを使うとよい

それでもだめな場合→がんばろう

Q.バイナリしかない場合→デスアセンブルすればよいのでは→ASICでネットリストもない場合はあきらめるしかないですかね→・・・
Q.マクロだらけのCのプログラムのデバッグ→undefineをよく使います。マクロを部分的に無効化していってデバッグする
Q.一番の敗北は？→soketとスレッドがぐちゃぐちゃになって結局ソースを捨てて書き直した
Q.講演になったキャッシュのノリが悪いとは？→一次キャッシュにのるようデータサイズを工夫して書いているはずがぱ性能が１桁でないのでしらみつぶしにしらべていった→解決したのか？→ソースを一つ前のリビジョンにもどしたら直ったorz ※キャッシュについては、linuxではoprofieというツールが便利。キャッスミスの場所が特定しやすい→HACK#
Q.並列プログラムで再現しないバグを根性以外で特定する方法？→根性以外の方法を知りません→（会場から）論理シミュレータ上でうごかしてみては？

■ Q&A

Q.デバッグを効率化するための新しいネタは
　→吉岡さん：コードを書かない　＆　テストドリブン
　
　→安部さん：よりいろんな種類のものに触れていく
　→島本さん：デバッグに関する考え方。なにが起きているか見極めてデバッグすることが大事（ツールの使い方よりも大事）。
　→岩本さん：気合。気合のあためにはちゃんと寝てご飯だべよう
　→大岩さん：ネタとして書いていたアイディアが、現実化しすることがある→fault indjectionなどの事例　このDEBUG HACKSもそういうきっかけになればいいな
　→吉田さん：仮想環境の上で動かす（再現、状況の保存がやりやすい）
　→Yuguiさん：EvilRubyというライブラリで、Cレベルにアクセスするライブラリがあるので、RubyのコードをCレベルで再現する。→Rubyのようなスクリプト言語からCのコードをデバッグすると効率がよい場合があるかも