「どうやって」デバッグするか

ちょっと昼休みにWeb界隈をブラブラしていて、面白い日記を発見。
未来のいつか/hyoshiokの日記
id:hyoshiokさんの技術関係日記。さらっと見て特に興味深かったのが次のエントリ。
2009-03-31 - 未来のいつか/hyoshiokの日記
2009-03-22 - 未来のいつか/hyoshiokの日記
超要約すると

dbg>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>printf

なんだけどデバッガを使ってデバッグする、という点にちょっとの違和感を覚えた。

日常的な開発業務の、まさにコーディング・単体テストみたいなところではデバッガをばんばん活用すればいい。でも、ここで摘出されるバグなんていうのは、それこそ小バエみたいなもんで。うるさいけど、まあ、ちょいちょいっと駆除できるわけです。もちろん、ここで摘出するべきバグを摘出しまくる事は絶対に大事だけど、バグ摘出の難易度という点ではそんなに高いものは少ない。

でだ

３年５年問題なく運用してきたけど、ここ数カ月トラブルが頻発している*1、なんていうヤツが手ごわい。こーゆーヤツにデバッガを使った手法はなかなか効かない（コアダンプの分析は有効です）。だいたい、アドホックなデバッグ実行みたいなもので出るようなら３年５年を耐えられないわけで。こんな時に頼りになるのは、Ａ３用紙に印刷したソースコードと赤ペン、青マーカーペン、シャーペン（鉛筆でもＯＫ）と消しゴムだ。あと、たまにホワイトボード。数万や数億に１回なんていうバグは、これらを使わないと駆除できない。printf（というか、妙な状態を検知したときに状況を報告する為のログ出力）は、事前に仕込んであれば助けになる事もある。最近は自分で分析する不具合はこんなのが多いので「ん？デバッガ？」と思ったんだろうな。

デバッガを使わないとわからん事もあるけどね。ＶＢ６*2で作られたソケット通信するプログラムが、データ受信のハンドラ内部で応答送信して、送信コンプリートをDoEventsしてチェックしようとしたら、他のデータ受信が先に動いてこれが延々と続いた挙句にスタックオーバーフローしたことがあった。この現象はデバッガを使って実行しているとスタックオーバーフローである事を教えてくれるけど、実行ファイルを動かしていると何の手がかりもないままプロセスが終了してしまう。ランタイムエラーのダイアログボックスが出ない。まあ、「ＶＢ６」という個別の製品の事情ではあるけど、そんな何かは他の製品でも、たぶんあるでしょう。

まあ、昼休みに日記みていて、ここまでは思ったんだけど、帰りの電車でつらつら考えた。「どうやって」って難しいなと。上に書いてあるのは使ったツールの話で、真の意味で「どうやって」に答えられていないと思う。俺は「どうやって」デバッグしているんだろう？
Algorithmic Program Debuggingというのは、その答えのヒントがある本なのかもしれない。

Algorithmic Program Debugging (Acm Distinguished Dissertation)

*1:「頻発」ならまだいいか。資料採取の機会が多いから、解決も近そうだ。業務上の大問題を起こしてしまったただ一回のトラブル、なんてのが恐ろしい。

*2:VisualBasic 6.0。検索ヒットするように、ちゃんとした名前を補う。