Debug Hacks Conference 2009

• 即売会あり
• 著者の自己紹介
• ⁵⁄₉(土) に新宿ジュンク堂でトークセッション
• ⁵⁄₂₈(木) にミラクル・リナックスでイベントやるらしい．
• Linux Sypodium の DOF をやりたい．

##まとめと感想

• Cとかメモリ周りの勉強したくなりました．

##あいさつ

• 吉岡さんによる「はじめに」の朗読
  • 学生や社会人1年生の時に読みたいと思った内容になっている

##著者によるデバッグネタ ###大和さん

• オライリーメーカーでの失敗談
• strace(#43)の話
• プログラムが実行する system call 一覧を表示する

###大岩さん

• アンケートで本以外のネタの要望が多かった．
• RPMコマンドによるデバッグ
  • /var/spool/clientmqueue/ にファイルがどんどんたまる
  • いつ誰が作ったかを調べる

# rpm -qf /var/spool/clientmqueue/
sendmail-8.13.8-2AX

• メールに関係するものだと見当がついた．
• ファイルを開くとメールだった．そして logwatch 送信者

# rpm -ql logwatch | grep etc
....

• cron(くろーん)
• /etc/crontab をみると，root 宛にメール送っていたのを修正した．
• スクリプトのデバッグ
  • bash -x で，実際に実行したスクリプトを表示してくれる．
• 裏話
  • LKMLにパッチ投げて採用された！

###安部さん

• もっぱら print デバッグ派
• でも gdb ネタを持ってきた．
• gdb ネタ
  • リストっぽい構造体をダンプする
  • ユーザ定義コマンドを定義すれば，ポインタアドレスを入れればきれいに表示できるので，デバッグしやすい！
    • 一つ一つやるのは大変．
  • debuginfo 付きバイナリのシンボル情報だけ利用する
    • debubinfo なしのバイナリで，シンボルだけ別に取得できた場合には使える
    • さらに楽な方法は？
  • デバッグ関数を追加する
    • C でデバッグ用関数を書いて，共有ライブラリにして，ロードする．

###Shimamoto さん

• #30 malloc()/free() で障害
• free()で落ちた？
  • backtrace すると確かに free() で落ちている
  • ライブラリ関数で落ちていても
  • たいていは，アプリケーション側で，2重解放，不正解放などが原因
  • デバッグ方法は
  • Valgrind / glibc の MALLOCCHECK

###吉田さん

• ネタが Linux Kernel に特化しているので，没ネタ紹介？
• トラブルシューティング Hacks
  • なんか突然止まった
  • 変更点を探す，が，そこにだけ注目してはいけない．
    • 相関関係 != 因果関係
  • トラブルを保存する．ダンプとか写真とか．バグ報告に十分な情報かを考える．
  • 真の目的をなにかを知る．
  • 具体的にいつまでに？
  • 最悪のケースとは？
  • ストップロス
  • 「仕様です．」
  • 問題を定義
    • 再現性は？
    • 再現環境は？
  • エラーメッセージは？
    • 英語メッセージは？
  • 事例調査する
    • ググる
  • 誰がやるのか？
    • 自分以外も候補として
  • 助言をもらえるとありがたい人などがいるか？
  • 責任と期限が決まったら行動
  • 最初は基本的なことから一つずつ調べる
  • 事前準備が必要
  • 覚悟
    • 壊れたら最悪どうするのか
  • 状況切り分け
  • クリーンインストールして再現したら解析開始
    • 再現しなかったら，再現するように環境を近づけていく
  • 再現したら，各種ツールと，DEBUG HACKS で解決しよう！

##Little debugging principles(Yugui さん)

• スケールアウト株式会社 / Akasaka.rb
• 先陣を切るから，みんなもっとすごいことしてくれー¹
• デバッグするときは
  • データの流れを見る
• 今日は Userland の話
• 昔は非同期処理，並列処理で苦労した
• 今日は Ruby
• Debug
  • 再現
  • ログをとる．重要．
  • 特定
  • 方法は BDD (RSpec)．仕様を満たす最低限のコードだけを書く．
    • 仕様の不足や仕様からの逸脱がわかる．
  • 修正
  • Legacy Code = テストがないコード
  • コードを見て，何故必要かを考えて，仕様を記述する
  • DbC = Design by Contract (規約によるデザイン)
  • デバッグでコードを追いかけるのは敗北
  • 負けたときは，what -> who
  • what
    • gdb -c / attach / 二分探索
  • who
    • 誰が？
    • データの流れを追う
    • gdb / シンボル
    • Ruby では gdb のために enum があったりする
  • それでも負けたときは，力ずくで試行する

###Q&A

• バイナリしかない場合は？
  • dis assemble すればいいんじゃないか．
• マクロ多用したものとかは？
  • マクロを部分的に適用するプリプロセッサを利用する
• 一番の敗北は？
  • Socket と Thread の関係がわからなくあって，ソースを捨てたこと．
• assertion をどれぐらい追加した？
  • 早期発見できたので，100ぐらいですんだ．
• 一次キャッシュののりが悪い
  • リビジョンを前に戻したら解決した．
  • oprofile でキャッシュミスがわかる．(#60？)
• 並列プログラムでデバッグで根性以外に何か方法は？
  • 根性です．
• 新しいデバッグ手法のネタ
  • TDD/BDD だとデバッグがテストの瞬間にわかるから，いいんじゃないかな？(吉岡さん)
  • より色んな種類のものにふれる(安部さん)
  • 何が起きてるか見極めてデバッグ．何を見たいのか(島本さん)
  • 気合い．そのためにちゃんと寝て食べる．(大和さん)
  • 三田さんの fault injection はいいんじゃないのかな？この本を読んだ方からそういう話がでるといいなと思っている(大岩さん)
  • 仮想環境の上で動かすとデバッグしやすいんじゃないかな(吉田さん)
  • Evil Rubyなどでスクリプト言語からデバッグすればいいのではないか．あと静的解析(？) coverity(?)も． (Yuguiさん)

comments powered by Disqus