19時よりDebug Hacks Conference 2009が開催されます。ustはこちらですって！ 時間に間に合うようにテレビの前に集まりましょう。
著者からひとこと
あいさつ / 吉岡さん
- まずは「はじめに」を朗読
- 著者は会社の同僚で、毎週編集会議をしてた
- ジュニアの頃に読みたかった内容にまとまった
- 実際にぶつかったバグを集めた
#43 straceについて / 大和さん
RPMコマンドによるデバグ+スクリプトのデバグ / 大岩さん
RPMコマンドによるデバグ
- 問題: /var/spool/clientmqueueにファイルがどんどん溜まる。溜まらないようにしたい
- いつ、誰が作成しているか不明
- rpm -qf コマンドで、ファイル名を指定 → モジュール名が出る
- この場合は、sendmail関連だったが、使ってないとのこと
- ファイルを開くと、Fromがlogwatch
- 次は rpm -ql logwatch | grep etc で、etc以下のファイル名を探す
- cronにあるっぽい
- 作られてるファイルを見ると、全て4:02だった → cron.dailyだね！ 解決
- ダブルクォーテーションだけ設定すればメールが飛ばなくなる。解決。
- ファイルを調べるにはrpmが役立つ。ファイルが不明な時はstraceでopenを捕まえる
裏話
- #18 SysRq キー関連
- LKMLにパッチ投稿した(sysrqキーのマスクが設定されてなかった)
- #32 無限ループ
- #34 リスト破壊
- posix-timers.c の不具合で実際に起きたバグを元に再現TPを作成した
- 問題のあったclock_was_set() と言う関数はなかったので、ネタにできなかった
- スライドがなくなってたとのこと・・・口頭で
- 他のパッチも投げたが、ダメ出しされて入らなかったのもあったとのこと
- 質疑応答
- Q. スライドがなくなってた不具合をどうやってデバグしますか？
- A. 緊張したんだと思われます・・・すみません
- 一番の貢献は、matzに推薦の言葉をもらったこと(吉岡さん談)
GDBネタ / 安倍さん
#30 malloc() free() の障害 / 島本さん
Debug Hacks Hacks / 吉田さん
- 童顔だけど、業界は15年
- ネタはかなりあるが、分野が違って使えなかった
- Debug Hacksを使うには、問題の切り分けが必要 = トラブルシューティング
- 動いてた物が突然動かなくなった場合
- 変わった部分に注目 → ただし、変わったものに因果関係があるとは限らない
- 相関関係 ≠ 因果関係
- 対処前に情報を保存
- トラブルの保存、メッセージの保存、dump、スクリーンショット、バグ報告用の情報
- 真の目的を見失わない
- やらないって方法もある → 代替サーバとか
- 期限
- ×なるはや ○いついつまで
- 期限内にできないと最悪何が起こる？(お金、時間、名誉)
- 大したことなければ後回しで
- ストップロス : どこまでコストをかけるか
- 「仕様です」
- トラブルとか問題じゃなく、「挑戦」「チャンス」として捉える
- 再現手順を用意
- 別環境でも再現する？？
- エラーメッセージ、英語メッセージ
- 事例調査
- サポートページ、ML、FAQ、マニュアル(ほんとはマニュアルを見るべきだが・・・)
- やっぱりgoogle → 海外の方が情報が多い
- 誰が対応するか
- 自分以外の専門家に御願いするのも手
- サポート部隊等
- 現象の調査
- "有効ならば" 手段を選ばない ← 本末転倒しないこと
- 確率の高い原因から検討 → 電源、ケーブル、断線
- システム構成要素のチェック → ハード、カーネル、ドライバー、アプリ、設定、データ
- 部品を一つずつ置き換えて行く
- 状態を変える → 再起動等 (バックアップ、情報収集、２重化とか準備してから)
- 事例: raid0のデータが壊れたと言う問い合わせ ・・・直らないよね
- 実環境とクリーン環境の違い
- クリーン環境で再現する？ 待機系で再現する？？
- 再現しなければ、環境を近づけて行く(バージョンとか。ディスクフルとか*2 )
- 再現したら ・・・ ツール色々使う
- 最終的にはソースと、DEBUG HACKSを使いましょう
閑話 / 吉岡さん談
- 日本初と言うこともあり、Rubyを書籍内でも取り上げた
- Mac版のDebug Hacksも欲しい。
- dankogaiさんにはFreeBSD版をお願いしたが、スルーされたっぽい。
- ブログとかでもいいので、共有できると楽しい。
- 年号「2009」を入れたのは、実は来年以降もやりたいから。」(吉岡さん談)。
まずカイより始めよ / Yuguiさん
- たくさんの人とデバグの話題を共有したい。先陣を切ります！
- 実はデバグあまりしない
- 今日はUser landの話
- 再現で困る不具合はあまりないが・・・
- 一次キャッシュに載りにくい
- スレッド系
- シグナルのタイミング
- printf を入れると、バイナリ位置が変わって再現しない
- Railsでのお話。再現は用意
- 再現→特定→修正 (特定が出来れば修正は簡単)
- 再現: ログが重要
- RoRのExceptionNotification → 入力値やセッションの値とかをメールで送ってくれる
- 特定: 易しい
- コードを書かない。BDD。
- 仕様を決めて、最低限のコードだけを書く。
- エラー = 仕様の不足・仕様への違反 → 自明であるはず
- 反復開発では、デバグは簡単
- 現実問題では・・・レガシーコードがある
- レガシー = テストがない
- コードを見て、なんのために必要か考える
- 仕様を起こす
- 仕様が不明なら削除 → 削除してエラーが起こらなければ、不要だった
- 削除してエラー → テストケースに起こす
- これはDebug？？ コードリーディング？ → コードリーディングはDebugの第一歩
- DbC (表明)
- RubyのRStringやRArrayの最適化(小さい値を自信で持つようにする)
- assertを入れまくるとドカドカ落ちる
- assertのエラーだけ対処した → バグは1つしか残らなかった
- デバグで苦労する状態になったら、負け
- 敗北することもある → データフローに注目。何がオカシイ。誰がオカシクシテイル。
- what
- 特定の環境だけで起こる - 外からatatchする
- 二分探索で、箇所を特定する
- tracerはあまり使ってない - OS Xだから。tracerが充実してない。いいのあったら教えて
- who
- データを壊した部分を見つける / その場 or 上流 or watch式 or 条件でbreakpoint
- データ抽出 : ユーザ定義コマンドを使う
- Rubyのdebug.c デバガ用のシンボル定義
- カーネル内での不具合に比べれば気楽だけど・・・
- スレッドorz 敗北 → 試行する。何度でも力づくで頑張る
- かしこい方法ない？ → あったらWEBに書いてね！！
- 質疑応答
- Q. レガシーコードでバイナリしかないとどうする？
- A. ディスアセンブルしてください
- A. 諦めるってのも一つの答えかもしれません・・・
- Q. マクロだらけのCのプログラムのデバグ方法は？
- A. undefine (マクロを部分的に適用する) をよく使う
- Q. 今までの一番の「敗北」はなんですか？
- A. socketとthreadの関係がわけわからなくなって、ソースを捨てて書き直したこと
- Q. assertion によって何個くらいバグを発見した？？
- A. 10とか、それくらいの記述数。早期発見が目的(100個のassertion)。そうでなければ組み合わせ爆発が起こっていたはず。
- Q. キャッシュのノリが悪いとは？
- A. データサイズを工夫してプログラムを書いていたのに、想定通りに1次キャッシュに載ってくれなかった
- Q. 原因はわかったのですか？
- A. 前のリビジョンに戻したら発生しなくなった
- oprofileと言うツールで、キャッシュミスを簡単に見つけられる = #60(吉岡さん談)
- Q. 並列プログラムで再現しない。根性以外の解決方法を聞きたい。
- A. 根性！
- A. 案: 論理シミュレータ状で動かすのはどうか
- Q. 既存の手法ではなく新しいネタを聞きたい
- A. バグを埋め込まないのが大切。TDDが非常に有効。(吉岡さん談)
- より色んなことに触れる
- デバグへの考え方。何が起きているか見極める。ツールの使い方だけではNG。
- 気合い！ 気合いを入れるためには寝て、ご飯を食べるのが大切
- #57 フォルトインジェクション は新しいのではないか (元々はネタだったが、本気にした人が形にしてくれた)
- ドライバ周りで不具合を洗い出した事例がある
- クレイジーなアイデアが、いいことを産む可能性がある
- 仮想化が有効ではないか。他のコンピュータでどんなノイマン型コンピュータもエミュレートできるはずなので。
- evilruby?? RubyのCレベルでのコードにアクセスできるもの / スクリプト言語の力を借りれるのであれば、GDBよりリッチな可能性がある
- coverity?? の静的解析。怪しいコードが結構出て来て、不具合を潰せる
- Q. 蚊遣りブタの理由は？？
- A. 蚊(虫)をとる。月曜日の夕方に延々と議論した結果。秋くらいから毎週17時。
- 互いの情報交換は新しい発見が多く、勉強になった。書くこともデバグ力を高めるのにいいのではないか。
告知
- 新宿ジュンク堂でもカンファレンスやります。
- 5/28(木) に、Debug Hacksのイベントをミラクル・リナックスでやる
- 10月のLinuxシンポジウムのKernelサミットで、Debug話をしたい
まとめ
ぜひ感想を聞きたい。いろんなデバグ法をフィードバックとして寄せて欲しい。
感想
今までデバグを題材の中心としたカンファレンスってなかったので、非常に新鮮で面白い集まりでした。また、 id:hyoshiokさんが気を遣ってくれたのか、深いKernelの話は余りなく、レベル的に昨日の Shibuya.pm に比べると大変聞きやすい内容でした。
デバグってのは本質的に失敗談を含んでるので、集まって話して楽しむには向いてる題材なのかもしれません。Debug Hacks と言う議論分野への可能性を感じました。
