理系院卒のネットワークなブログ

意外なところに「つながり」ってありますよね

やっかいなメモリ関連のエラーのデバッグ

 

f:id:ytera22:20140705181324p:plainf:id:ytera22:20140705181321p:plain

visual studioでプログラムを組んでいる時に、出てきてほしくないエラーの1つに『・・・ヒープが壊れていることが原因として考えられます・・・』ってやつがありますよね。どこでエラーが出ているのかぱっと見では分からないタイプのバグです。

ヒープと明記するぐらいなので、メモリの確保or解放処理でエラーが出ていることはすぐにわかります。メモリにからむプロセスを1つ1つ潰していって(printfなどを駆使して)、発生原因を特定しますよね。でもやっかいなことに、このタイプのエラーはエラーのたびに発生場所が変わったり、エラーメッセージが変わったりしませんか。僕はよくそうなってしまいます。

こうなるともうお手上げ状態です。ほんとにイライラしますよね。先日もこれのせいで2時間ぐらい無駄にしました。2時間悩んだ末に原因を特定したのですが、ものすごく初歩的なミスでした。発生するたびに原因が変わっているんじゃないかと思うほどの大げさなエラーだったのに、蓋を開けてみればメモリ確保時に1を無駄に引いてしまっていて、確保していない領域に値が書き込まれていました。

このようなミスをしてしまった場合、ミスのあるメモリ処理の次のメモリ処理から影響が出てくることが多いです。次のメモリ確保やメモリ解放が遠くにある場合、エラーの原因に気づくまでに相当な時間がかかってしまいます。僕がハマったバグに関しても、エラーが出ているプロセスとエラー原因はこれっぽっちも関係のないものでした。だから単純なミスにも全然気づけなかったのです。

今度このようなエラーが出た場合は、そのエラーが出始める箇所だけでなく、その前のメモリ確保・解放にも目を向けてみることにします。それを忘れないためにここに書いておきます。僕は以前もこのようなエラーでハマった覚えがあるので、こういうエラーを生みやすいコードの書き方をしているのだと思います。書く順番などのコードの書き方は人によって個人差があると思います。僕のこのメモを見てもなんにも役に立たない人もいるかとお思いますが、ひとりでも苦戦しているエラーを解決できた人がいたなら、書いた意味が倍になるというものです。お互いがんばりましょう。