メモ
時系列で取ったメモを残しときます。PCなかったんできつかった。
19:15- 大和さん
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
- 相関関係≠因果関係
- 大事なのはトラブルの保存
- ログ
- メッセージ
- ダンプ
- スクリーンショット
- 必要なら写真
- トラブルシューティングの心構え
- 真の目的を心得る（やらないという選択肢も視野に）
- 期限を確認
- ストップロスを計る。見積もり大事。
- ポジティブに捉える
- ×トラブル、問題
- ○チャンス
20:30- Yuguiさん
「先ず隗より始めよ」
みんなで情報共有してみんなでナレッジを増やしていきましょう。
デバッグに関して
- 再現させることが大事。気合い。
- コードは必要最低限しか書かないように。仕様ありき。
- assert()で吐きまくり。
お知らせ
- 5/28にミラクルリナックスでDebug Hacksのイベント開催
- 10月のLinuxシンポジウム＠秋葉原でもまたDebug Hacks Conference的なことをしましょう
*1:ただしランダマイズな時は使えません
