• 即売会あり
  • 著者の自己紹介
  • 5/9(土) に新宿ジュンク堂でトークセッション
  • 5/28(木) にミラクル・リナックスでイベントやるらしい．
  • 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 の MALLOC_CHECK_

###吉田さん

  • ネタが 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さん)

Footnotes

  1. それは無理そうなんですが・・・・ ↩