Debug Hacks Conference 2009

debug hack conference

まとめと感想

  • 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 宛にメール送っていたのを修正した．
  • スクリプトのデバッグ
  • 裏話
    • LKMLにパッチ投げて採用された！
安部さん
  • もっぱら print デバッグ派
  • でも gdb ネタを持ってきた．
  • gdb ネタ
    • リストっぽい構造体をダンプする
      • ユーザ定義コマンドを定義すれば，ポインタアドレスを入れればきれいに表示できるので，デバッグしやすい！
        • 一つ一つやるのは大変．
      • debuginfo 付きバイナリのシンボル情報だけ利用する
        • debubinfo なしのバイナリで，シンボルだけ別に取得できた場合には使える
        • さらに楽な方法は？
      • デバッグ関数を追加する
        • C でデバッグ用関数を書いて，共有ライブラリにして，ロードする．
Shimamoto さん
  • #30 malloc()/free() で障害
  • free()で落ちた？
    • backtrace すると確かに free() で落ちている
    • ライブラリ関数で落ちていても
      • たいていは，アプリケーション側で，2重解放，不正解放などが原因
    • デバッグ方法は
吉田さん
  • ネタが Linux Kernel に特化しているので，没ネタ紹介？
  • トラブルシューティング Hacks
    • なんか突然止まった
      • 変更点を探す，が，そこにだけ注目してはいけない．
        • 相関関係 != 因果関係
      • トラブルを保存する．ダンプとか写真とか．バグ報告に十分な情報かを考える．
      • 真の目的をなにかを知る．
      • 具体的にいつまでに？
      • 最悪のケースとは？
      • ストップロス
      • 「仕様です．」
      • 問題を定義
        • 再現性は？
        • 再現環境は？
      • エラーメッセージは？
        • 英語メッセージは？
      • 事例調査する
      • 誰がやるのか？
        • 自分以外も候補として
      • 助言をもらえるとありがたい人などがいるか？
      • 責任と期限が決まったら行動
      • 最初は基本的なことから一つずつ調べる
      • 事前準備が必要
      • 覚悟
        • 壊れたら最悪どうするのか
      • 状況切り分け
      • クリーンインストールして再現したら解析開始
        • 再現しなかったら，再現するように環境を近づけていく
      • 再現したら，各種ツールと，DEBUG HACKS で解決しよう！

Little debugging principles(Yugui さん)

  • スケールアウト株式会社 / Akasaka.rb
  • 先陣を切るから，みんなもっとすごいことしてくれー*1
  • デバッグするときは
    • データの流れを見る
  • 今日は 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さん)

*1:それは無理そうなんですが・・・・