YAMAGUCHI::weblog

土足で窓から失礼いたします。今日からあなたの息子になります。 当年とって92歳、下町の発明王、エジソンです。

Debug Hacks Conference 2009に行ってきた

概要

Debug Hacksの発刊を記念して開かれたカンファレンス。即売会や限定Tシャツ販売などもあって楽しかった。

メモ

時系列で取ったメモを残しときます。PCなかったんできつかった。

19:15- 大和さん

ネタ

O'Reilly MakerがなぜかGoogle検索トップにきて残念。

straceについて

とりあえず不具合がでたときに使ってみると便利。定石は「最後から見る」
さらに-iオプションをつけるとエラーが発生した箇所のアドレスが分かるので、GDBブレークポイントをそこで打ってやってからバックトレースすると便利。*1

19:20- 大岩さん

RPMコマンドによるデバッグ
  • 問題

/var/spool/clientmqueueにファイルがどんどんたまるエラーが発生。これを直してほしい。

  • 切り口

いつ、だれがそれを作っているのか?

  • 手がかり

RPMコマンドの-qfオプションを使う

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

これでメール関係じゃないかと疑うもお客さんは「使ってないよ」という。でもとりあえずsendmailが関係していることは分かった。次はディレクトリ配下のファイルを調査。するとやはりファイルの中身はメールになっていて、送信者がlogwatchになっている。
今度はRPMコマンドの-qlオプションを使う。

# rpm -ql logwatch | grep etc

grep etcを噛ませたのは設定ファイルを確認したいため。確認してみるとcron.dailyが関係していると分かる。結局そこを調査したらログのメールの宛先がrootになっていたことが原因だった。

  • 結論

ファイル関係はRPMコマンドが便利。またスクリプト言語であればstraceを使うとどのファイルを参照しているかはopen()を呼んでいるところを見ればすぐに分かる。

19:30- 阿倍さん

GDBは使いこなすのが大変。

  • たとえばdebuginfoがないときにどうやってリストのダンプを見るか

これはなかなか難しい。そこで「ユーザ定義コマンド」を利用する。頑張れば結構きれいに出力できる。ただし環境依存だったりするので大変。

  • debuginfoがあるなら
(gdb) symbol-file debuginfo

とりあえずこれでシンボルが読めるので安心安心。それでもユーザ定義コマンドで書くのは大変です。

  • Cで関数書いて共有ライブラリ化

だったらはじめからCで関数書いてしまえばちょっとはリッチに書けるじゃないか。

$ LD_PRELOAD=foo.so gdb ./hoge

19:45- 島本さん

malloc(), free()で障害が発生したときはどうするか?(特にライブラリ関係で発生したとき)

まずはアプリのバグであると思った方がよい。

  • 二重解放
  • 不正アドレス解放

この原因を探るには下記が使えるはず

19:55- 吉田さん

デバッグを始める前にはたくさんの準備が必要である。

トラブルシューティングHacks
  • 相関関係≠因果関係
  • 大事なのはトラブルの保存
  • トラブルシューティングの心構え
    • 真の目的を心得る(やらないという選択肢も視野に)
    • 期限を確認
  • ストップロスを計る。見積もり大事。
  • ポジティブに捉える
    • ×トラブル、問題
    • ○チャンス
いよいよデバッグ

目的のために、有効ならば、手段を選ばず(マキャベリズム)

  1. 別環境で動作するか?
  2. メッセージを確認
    1. 調査(=ググれ)
    2. FAQ
    3. サポート
    4. マニュアル
  3. 対応すべき人を確認
  4. 構成を確認。再現するまで「1つずつ」変更。
    1. ハードウェア
    2. カーネル
    3. ドライバ
    4. データ
  5. システムの状態変更
    1. 再起動
    2. プロセス停止
  6. そもそもトラブっても大丈夫なようにしようね
    1. データバックアップ
    2. システムバックアップ
    3. 定期的な情報収集:sar
    4. 自動dump

20:30- Yuguiさん

「先ず隗より始めよ」
みんなで情報共有してみんなでナレッジを増やしていきましょう。

デバッグの心
  1. デバッグしない -- それが一番です
  2. デバッグするときはデータの流れを見る -- 悪さするのはデータです。
  3. userlandでのデバッグは自明である -- だって自分で書いたんだから
デバッグに関して
  1. 再現させることが大事。気合い。
  2. コードは必要最低限しか書かないように。仕様ありき。
  3. assert()で吐きまくり。

お知らせ

  • 5/28にミラクルリナックスでDebug Hacksのイベント開催
  • 10月のLinuxシンポジウム@秋葉原でもまたDebug Hacks Conference的なことをしましょう

おまけ

na-toi君と知り合いました。今度Java教えてもらいますw

*1:ただしランダマイズな時は使えません