4/23(木)にDebug Hacks Conference 2009に参加してた。実のところ、いわゆる最近流行の"勉強会"に参加するのはこれが初めて。最初ちょっとどきどきした :D
最初に感想
かなり面白く、また有益なカンファレンスだった。実際日頃から開発をしている人の考え方やアプローチを聞くことができた。
ところで、今回の参加者の方はやはり仕事で開発をされる方や、趣味で開発をされている方が多かったのだろうか。そこは実は結構気になるところだったりする。なぜなら自分は開発者ではないからだ。趣味で開発をしないといったら嘘になるが、仕事でソースコードに触れる機会はほぼないし、学生時代と比べて日常的にソースコードに触れることはほとんどなくなってしまった。
しかしながら、仕事ではコンサルティングといったことを行うため、さまざまなシステムを見る機会がある。そこではパッケージ製品やお客様の重要なシステムのように、ソースコードにアクセスできないものが多々ある。そのような場合printf()デバッグなんてそもそもできないわけで、限られた情報やツールを使ってシステムを解析し、問題点を特定する必要がある。
Conference中に「バグは自明である」という言葉が登場した。まったくもってその通りだと思う。しかしソースコードを見ることができないシステムのように、外から隠ぺいされた場合バグは自明ではなくなってしまう。
今回、書籍DEBUG HACKSやDebug Hacks Conferenceに期待した内容は、上述したように如何にして"非破壊的"にシステムの問題点を特定するかである。その方法はログを見るといった基本的なところから始まり、straceなどのツールを使うこともあるだろう。もちろんアーキテクチャを知らなければ、ツールを使えたとしても本質的な部分へのアプローチは難しい。
今まで断片として学び経験してきたDebug手法だが、DEBUG HACKSを通して、これらの基本及び応用を、体系だって再度学んで行きたいと思う。
発表内容の詳細は他の方がblogで詳しく書かれているし、そもそも動画もアップされているので、中身についてはメモ程度に。
よしおかさん
書籍DEBUG HACKSの "はじめに" を朗読。
大和さん
自分は参加登録のページでの投票にstraceの話を聞きたいと投票したのだが、したかいがあったかな。
～strace～
・straceの定石は最後から見る
・strace -i でアドレス表示
→ アドレスを使ってgdbでブレークポイント
Q：アドレスがランダマイズされる場合はどうすればいい？
A：基本的にはそういう場合は使えない。それが起こらない環境でやるしかない。
大岩さん
RPMコマンドの -f オプションや -lオプションのことは初めて知った。そういう使い方もあったのかと。sh -x はよく使ってる。デフォで使っておきたい。
～RPMコマンドによるデバッグ～
問題：/var/spool/clientmqueue/ にファイルにどんどんたまる
解決：ファイルが作成されないようにしたい
疑問：いつ誰が作ってるか分からない。
・こういうときはrpmコマンドを使う
# rpm -qf /var/spool/clientmqueue
→ sendmail-8.13.802.2AX と表示されるのできっとメール関係
・実際に生成されるファイルの中身を見る。
→ logwatch が書かれていた
# rpm -ql logwatch | grep etc
～スクリプトのデバッグ～
・bashであれば -x オプション
→ 結果だけでなく、実行されたコマンドも表示される。
安部さん
～GDBネタ～
・ユーザー定義コマンドが便利
→ debuginfoがなくても、がんばればきれいに構造体をダンプできる。
→ でもアドレスとか変わっちゃうだけで使い物にならなくなる。
→ やはりdebuginfoのシンボル情報だけでもあると楽
島本さん
～malloc() free()で障害～
・free()でsegmentation faultが起こった。
・大体の場合はこれはアプリケーションのバグ
- 2重開放
- 不正アドレスの開放
・デバッグ方法は
- メモリバグ検出ツール（Valgrind）
- glibcのMALLOC_CHECK
吉田さん
～Debug Hacks Hacks～
・Debug Hacksを使うためには、問題をの切り分けが必要。
・相関関係≠因果関係
・真の目的は何かを考える？
→ 期限は？
→ "できるだけ早く"ではダメ。明確に。
→ 最悪のケースを考える
・事例調査
・誰が対処する？
→ 自分より効率的に対処できる人や団体。助言をもらえる人。
・責任と期限を決めたら行動ありき
・目的のために、"有効ならば"手段は選ばず。
→ つまり本末を転倒しない
・原因は？
→ 疑わしいものがあったら１つずつ試す。
→ まとめてやるとどれが原因か分からない。
・事前準備
各種バックアップなど
・覚悟を決める
→ 壊れたら最悪どうする？
・切り分けの方法
→ 再現性
→ 再現手順が100%になったらほぼ完璧
Yuguiさん（園田裕貴さん）
・Rubyそのものの開発のお話
・バグを再現させる
・しかし現実にはレガシーコードの存在
→ テストがないコード
→ そのコードはなぜ必要？本当に必要？
→ 不要だと思うなら削除
→ 削除しても動くなら本当にいらないコード
・バグは自明である
→ assertをたくさん仕掛ける
→ assertを消していったら最終的に1箇所しか残らなかった。
・デバッグで特定に苦労する時点で敗北
→ しかし負けることもある。
・バグを二分探索
・誰(何)がデータを壊したか？
1. その場で壊された → 自明
2. フレームを上に上る → 引数
3. ひたすらwatch、条件でbreak point
・それでも敗北するときもある。マルチ・スレッド。
→ 最終的には試行錯誤
おまけ
Q：本の表紙が蚊取り線香なのは？
A：むしをとりましょう
→ 蚊取り線香
よしおかさんから告知
・5/9に新宿のジュンク堂で、共著のみなさんとお話し
・5/28(木)参加できなかった向けに、またイベントを開催。ミラクルリナックスの会場予定。
・Japan Linux Symposiumが10/21～23に秋葉原で開催。Linusとかも来る。
戦利品
