Debug Hacks Conference 2009

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とかも来る。

戦利品