デバッグしていく前には、当然バグが起こる厳密な場所はわからない。
なので、マクロな範囲からミクロな範囲へと絞っていくのがデバッガの役目である。(コール命令をまたいだ瞬間バグが起こるなら、そこでステップ・インすれば、よりミクロな範囲に絞れる)
ブレイクポイントがごちゃごちゃになるのは、主に次の場合だと思う。
・新たに貼ったブレイクポイントが、これまでのブレイクポイントよりも先に大量にヒットする。
→これは大いに有り得る。新たなブレイクポイントはこれまでのブレイクポイントより局所的である(つまり、より小さな汎用的な部品である可能性が高い)から、色んな場所から呼ばれる可能性が高い。
ここで意識すべきなのは、新しく貼ったブレイクポイントがこれまで貼ったどのブレイクポイントよりも後にブレイクするなら(つまり、最後にブレイクするなら)、このブレイクポイントはこれまでのどのブレイクポイントよりもバグに近い。
(当然、バグが発生するまでにブレイクポイントは貼るべきだ。もし、バグが起こってしまった後に貼っているブレイクポイントなのであれば、いくら上の条件を満たしていても意味がない。)
この事実は、新しく貼ったブレイクポイント以外のブレイクポイントをすべて消去してもよいという結論を導き出す。
「デバッグしているうちに新しく貼ったブレイクポイント(論理的に貼ったもの)が、これまでに貼ったどのブレイクポイントよりも後にブレイクするなら、このブレイクポイントだけを残して、他のすべてのブレイクポイントを削除して良い。」
このブレイクポイントは起点になり、よりデバッグを楽にすると思う。
でも、そんな便利なブレイクポイントがみつからないことがあるかもしれない。
そんな場合は、まず手頃なブレイクポイントを見つける。そして、１つ目以外のブレイクポイントをすべて無効にしておく。
はじめの一つのブレイクポイントがヒットすると、次のブレイクポイントだけをONにする。
そして、次のブレイクポイントもヒットすると、その次のブレイクポイントをONにする。
といった風にすると、無駄なブレイクが発生しないかもしれないが、かなり手間がかかるので使いにくい。
