プログラマのつれづれなるままにプログラマのつれづれなるままに音宮志久が思ったことなどをネタにします。プログラムネタ・数学ネタがメインです。デバッグの仕方を間違えるとはまるメモリネタデバッグの仕方を間違えるとはまるメモリネタコメントを残すこれをやっていたのは実は昨日なのですが、あまりにもひどい思い違いを自分がしていたのでそれについてのコメントです。変数メモリが破壊される?という現象に悩まされていました。いうか、今までそんな現象が出たことがないモジュールであり、モジュールがいくつか絡んでいる処理なのですが、それぞれのモジュールを単一でテストするとエラーが出ない。それらを絡ませるとなぜか途中でメモリが破壊される。これだけ書くと「いったいなぜ?」と思いたくなると思います。この現象が出たときに自分が思っていたことも同じでしたので。いくつかデバッグをしているうちにどうやらメモリ破壊が起こるのはSTLのルーチンらしい、ということになり、デバッグビルド/リリースビルド関係を確認していたのですが、どうもそうでもない。意味不明だぞ・・・と。ブレークポイントを後ろのルーチンに設定すると前のルーチンでのメモリ破壊によるエラーは出ないブレークをかけないようにするとステップ実行でメモリ破壊が起きていた部分ではメモリ破壊エラーが起きずに正常に実行できる。思い返しているうちに何となく理由が読めてきました。いうのも、テストしているプログラムですが、概略的にはこんな感じです。0;}・・・何となくわかるでしょうか。賢明な人であれば何が起こったのかわかると思います。スレッドが作成されてそちら側の処理が並列でスタートするSleepの2000msが経過してdelete命令によりg_itemBは破棄されるこの時点でg_itemBのメモリはヒープに返却するそんなことを知らずCItemA::fやCItemB::gは呼び出されるので、破棄されたメモリにアクセスしたり、STLでヒープからメモリがとられるとg_itemBの領域のメモリが使用されて壊れたように見えるという現象になります。スレッドが挟まっていたことと、デバッグルーチンだから、とSleepで待ち制御を行っていたために起こった自分で作ってしまったバグでした。悩み始めてから風呂に入るまでにだいたい2時間~3時間くらいこれに悩んでいたのでただの間抜けですね。スレッドが絡んでいるとメモリ破壊もこれだけわかりづらい理由で起こる、ということも覚えておく必要があります。これは簡略化するとそれなりの人がわかるように見えるだけで実際のルーチンはさらに複雑(スマートポインタクラスによるdeleteの隠蔽など)なので、こういう風に見える、という変換もできないとだめですね~。コメントをキャンセルメールアドレスが公開されることはありません。名前メールサイトΔ{{#message}}{{{message}}}{{/message}}{{^message}}送信は失敗しました。{{status_code}})。このフォーム処理機能の開発者に連絡して、このメッセージを改善してください。詳しく{{/message}}{{#message}}{{{message}}}{{/message}}{{^message}}送信は成功したようです。送信が処理されていない場合があります。このフォーム処理機能の開発者に連絡して、このメッセージを改善してください。気になるプログラムネタや数学ネタがあったら書き込みたいのだが残業が長すぎて眠気が全くとれず体調があまりよくない。過労などでぶっ倒れるかもしれない。あと、さすがに独り身が寂しいのでなんとかしたいと考えてはいるのだが...。アクセスカウンタアクセス数:スポンサーリンクモバイルバージョンを。