Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

今日は Debug Hacks Conference 2009 の日です

19時よりDebug Hacks Conference 2009が開催されます。ustはこちらですって! 時間に間に合うようにテレビの前に集まりましょう。

著者からひとこと

  • 他の方が面白いネタをやってくれます/吉田さん
  • 実はほんとに泣いたことがあります/安倍さん
  • グリーンのTシャツ着忘れました/大和さん
  • いつもカーネルデバッグしてます/大岩さん
  • 普段デバグしてるので書けると思ったら結構大変でした/島本さん

あいさつ / 吉岡さん

  • まずは「はじめに」を朗読
  • 著者は会社の同僚で、毎週編集会議をしてた
  • ジュニアの頃に読みたかった内容にまとまった
  • 実際にぶつかったバグを集めた

#43 straceについて / 大和さん

  • オライリーで出せるとは思わなかった
    • オライリーメーカーで AKB48 って本作ったけど、消し方がわからない(一年放置中)
    • 消費電力さげるネタでも書きたい → Windowsとかの技術者募集
  • strace とは? → システムコール呼び出しの監視
  • /etc/shadow を開こうとすると、たくさんの行が出力され過ぎる
    • 最後の方から見るのがいい
  • -iをつけると、アドレスが表示される
  • 質疑応答
    • Q. ランダマイズされる場合は?
    • A. 基本的には使えない。ない環境で。

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 無限ループ
    • カーネルがストールする現象を再現させる予定が、tcpdumpがストールしたのでそっちをネタにした
  • #34 リスト破壊
    • posix-timers.c の不具合で実際に起きたバグを元に再現TPを作成した
    • 問題のあったclock_was_set() と言う関数はなかったので、ネタにできなかった
  • スライドがなくなってたとのこと・・・口頭で
    • 他のパッチも投げたが、ダメ出しされて入らなかったのもあったとのこと
  • 質疑応答
    • Q. スライドがなくなってた不具合をどうやってデバグしますか?
    • A. 緊張したんだと思われます・・・すみません
    • 一番の貢献は、matzに推薦の言葉をもらったこと(吉岡さん談)

GDBネタ / 安倍さん

  • 実はprintデバグ派です・・・そこをあえてGDBネタで
  • GDBはなんでもできるが、使いこなすのは難しい
    • 例えば、複雑なデータ構造を見るのは辛い
  • 例: 構造体リストのダン
    • お客さんとこではdebuginfoないしprintコマンド使えない
    • ユーザ定義コマンド: よく使うコマンドをまとめられる
    • 構造体を表示するコマンドを作ると楽
    • ↑を利用して、再帰してリストを全て出すコマンドも作れる
  • debuginfoがやはり欲しいとき
    • debuginfo付きのバイナリを用意して、symbol-fileだけロードさせることができる
    • 全然違うバイナリは当然無理。対応するものを用意する必要あり。
  • debuginfoが手に入れば、ユーザ定義コマンドがかなり簡単になる
  • それでも辛い時 → デバグ関数を追加
    • GDBスクリプトじゃなくてCで書く
    • 共有ライブラリにし、LD_PRELOADとしてロード
    • 長所: 何でも出来る
    • 欠点: 当然アプリの再起動が必要。core解析の時は使えない
  • 質疑応答
    • Q. debuginfo がデフォルトで全部入ってるようなディストリないの?もしくは作らない?
    • A. インストーラを作ってる方が会場にいる。捕まえて話をして欲しい。
    • Q. GDBフロントエンドは使わないの??
    • A. GUI苦手。一行ずつ書いてます。
    • Q. Hello Worldもろくに書けない*1のにカーネルの世界に入ったのはなぜ?
    • A. 自分でもよくわからない。落とし穴に落ちた。

#30 malloc() free() の障害 / 島本さん

  • free() 内部でのセグフォ
    • ライブラリ関数はデバグできないと思う。Kernel panicと同じイメージ。
    • 実はアプリのバグであることが多い(二重フリーとか)。デバグできないと考えないこと
  • Valgrind を使うといい。glibcMALLOC_CHECK_とかも運が良ければ。
  • アプリケーションによるところも多い
  • カーネルパニックが起こると・・・? → ラッキー
    • ネタができた!!
  • 質疑応答
    • Q. ライブラリの不具合も追いかける?
    • A. これはライブラリのバグですと突き返すことが多い
    • Q. kmallocの不具合ってありますか?
    • A. 遭遇したことがない。
    • A. calledinjection(?)などで責めれる
    • Q. カーネルの場合はどうなるのか? 同じようなツールはあるのか
    • A. 書籍内部で紹介はある。MLの中でカーネルメモリリークについて見たことがある。カーネルオプションにありそう。

Debug Hacks Hacks / 吉田さん

  • 童顔だけど、業界は15年
    • ネタはかなりあるが、分野が違って使えなかった
  • Debug Hacksを使うには、問題の切り分けが必要 = トラブルシューティング
  • 動いてた物が突然動かなくなった場合
    • 変わった部分に注目 → ただし、変わったものに因果関係があるとは限らない
    • 相関関係 ≠ 因果関係
  • 対処前に情報を保存
  • 真の目的を見失わない
    • やらないって方法もある → 代替サーバとか
  • 期限
    • ×なるはや ○いついつまで
    • 期限内にできないと最悪何が起こる?(お金、時間、名誉)
    • 大したことなければ後回しで
  • ストップロス : どこまでコストをかけるか
    • 「仕様です」
    • トラブルとか問題じゃなく、「挑戦」「チャンス」として捉える
  • 再現手順を用意
    • 別環境でも再現する??
    • エラーメッセージ、英語メッセージ
  • 事例調査
    • サポートページ、ML、FAQ、マニュアル(ほんとはマニュアルを見るべきだが・・・)
    • やっぱりgoogle → 海外の方が情報が多い
  • 誰が対応するか
    • 自分以外の専門家に御願いするのも手
    • サポート部隊等
  • 現象の調査
    • "有効ならば" 手段を選ばない ← 本末転倒しないこと
    • 確率の高い原因から検討 → 電源、ケーブル、断線
    • システム構成要素のチェック → ハード、カーネル、ドライバー、アプリ、設定、データ
    • 部品を一つずつ置き換えて行く
    • 状態を変える → 再起動等 (バックアップ、情報収集、2重化とか準備してから)
    • 事例: 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時。
    • 互いの情報交換は新しい発見が多く、勉強になった。書くこともデバグ力を高めるのにいいのではないか。

告知

まとめ

ぜひ感想を聞きたい。いろんなデバグ法をフィードバックとして寄せて欲しい。

感想

今までデバグを題材の中心としたカンファレンスってなかったので、非常に新鮮で面白い集まりでした。また、 id:hyoshiokさんが気を遣ってくれたのか、深いKernelの話は余りなく、レベル的に昨日の Shibuya.pm に比べると大変聞きやすい内容でした。

デバグってのは本質的に失敗談を含んでるので、集まって話して楽しむには向いてる題材なのかもしれません。Debug Hacks と言う議論分野への可能性を感じました。

*1:書籍の紹介に書いてます

*2:ディスクフルに"なったことがある"と言う状態で変わることもあるとのこと