アプリ版:「スタンプのみでお礼する」機能のリリースについて

VS2010を使用しています。
複数人で同じプロジェクトを編集しています。
いつからか「Detected memory leaks!」が多発するようになり、Dumping Objectsの結果からいくつかは修正できたのですが、
----------------------------------------
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {34985} normal block at 0x05ECE620, 104 bytes long.
Data: < }R+ + > 84 CF 7D 52 2B 00 00 00 2B 00 00 00 01 00 00 00
----------------------------------------
上記の内容だけは意味がわかりません。
他の回答に「_CrtDumpMemoryLeaks」の実行場所をできるだけ後にするというようなことで対策できたようですが、このプロジェクトでは、記述していません。(明示的には実行していない)

何か、何かアドバイスをいただけたら助かります。
よろしくお願いいたします。

A 回答 (1件)

初めまして。

ゲーム業界でメインPGやっている者です。プログラマ歴は10年位です。

エラーメッセージから推測するに、CRTデバッガが吐き出すリーク検知時のメッセージでしょうか。
(メモリアロケータ等は自作でCRT等のツールは使った事無いので分かりませんが・・)

コードが無いので何とも言えませんが、そのメッセージ自体は調べたところ、
MFCのstrcore.cpp156行目の処理によるエラーで34985回目のメモリ確保時に出ている様です。
(3万回以上経ってなら、大方のリークは潰した後の小さなリークの累積なんでしょうね。骨が折れている事と思います)

その際のメモリ確保はヒープ上の0x05ECE620と言うアドレスから始まっていますが、104バイトのメモリブロックが未解放。
(解放していないメモリブロック上に確保をかけて失敗している)

そして、その失敗しているメモリブロックの中身は、}R+ + となっている。
その}R+ + をバイナリとして表すと、84 CF 7D 52 2B 00 00 00 2B 00 00 00 01 00 00 00

と言うのが直訳した結果です。

VC上のIDEであればヒープ位置は変わらないと記憶しているので、
・0x05ECE620と言う数値が何度実行しても変わらないのであればそのアドレスが変更された際にブレークをかける
・104バイト確保と言う事なので、そのサイズの構造体やクラスに心当たりが無いか考える
・使用している実値データに84 CF 7D 52 2B 00 00 00 2B 00 00 00 01 00 00 00が無いか
・MFCのstrcore.cppが見えるなら156行目にブレークを貼ってコールスタックを追う。
等から追跡して、そのデータの確保タイミングを見つける位は出来るかも知れません。

この手の事例は単に生成順と解放順が管理されていない事による不整合が大半だと思います。
綺麗にクラス化された設計なら、該当しそうなオブジェクトのデストラクタと、新オブジェクトのコンストラクタにトレースなりブレークを貼って、順番のおかしい箇所を探すのが、地味で手間に見えますが確実です。

リークは大変ですよね。
起きた際の事後解決能力も必要ですが、起こさない為の工夫も、考えると山ほどあります。
是非がんばって下さい。
    • good
    • 0
この回答へのお礼

お礼が遅れ、申し訳ありません。
丁寧な回答ありがとうございます。
アドバイスいただいた内容をもとに、リーク箇所を探してみたいと思います。

お礼日時:2011/08/17 08:58

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!


このQ&Aを見た人がよく見るQ&A