kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

バグの見つけ方

バグを発見する典型的なやり方ってありますか? | スラッシュドット・ジャパン ITより
私だったらまず

  • メッセージだしているところをgrepで探す。
  • なんで"NO LINE"なのかチェックする。Windowsだったらパフォーマンスモニタとかタスクマネージャ、あるいはProcess Explorerで見て、どの資源を食っているのか見る。
  • 近辺のソースツリーを順に見ていく。

…かな。たぶんこれでおおざっぱには見つけられそうな予感がする(w3m使ったことないのですが)。コメントも少しじっくり読んでみたのですがやっぱみな同じようなことやっている人が多いですね(^^;。

  • 電車の中とかお風呂とか、寝ようとしているときに気がつく
  • 誰かに語って気付く(告白デバッグのクマさん有能だ。これは私の周りでも是非導入したい)。

あと私も似たようなことやってしまったのですが、デバッグパターンで紹介されている「再生成したらなぜかなおった」とかありまして…。たいていそういう時ってものすごくせっぱ詰まっているときで、生成コードも追えませんorz。
周りも「Windows Server 2003で動かしたら動作が違う。Windows Server 2003が狂っているに違いない!」(なぜかこの原因が最初に浮かぶらしいです。ほとんどどこかのコードに問題があるのに)。とかいう人多いです。クマさんに告白して、何が起こっているのか整理して考えましょう。私も人のことあまり言えませんが…。
一連のコメントでもありますが、Cのprintfは書式制御やる都合上、他に比べてコストが高いです。また、今はそれほどでもないんですが、昔の…NT3.1〜3.5(1)とかの時代はビデオドライバがちょっと割り込みをとりすぎていると、シリアル関係のデバッグしているのに、シリアルがデータをぼろぼろ取りこぼすと言うことが日常茶飯事で泣けました。なんで、printf()はシビアなところには使わずにputs()とか、OutputDebugString()かな。Cだったらその手のマクロを用意してifdefで切り分けてましたね。