Sign in to follow this  
Sfpiano

Memory leaks

Recommended Posts

Sfpiano    126
I've been reading a series of posts on catching memory leaks, but so far none of them have worked. I've noticed that all of them involve #define _CRTDBG_MAP_ALLOC; however when I define that, I get a series of repeated errors:
LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int,int,char const *,int)"

Share this post


Link to post
Share on other sites
Sfpiano    126
Ok, I decided to start a new project and I included that info from MSDN and I get this:


Dumping objects ->
{47} normal block at 0x008E0F20, 792 bytes long.
Data: <September > 53 65 70 74 65 6D 62 65 72 00 CD CD CD CD CD CD
{46} normal block at 0x008E0D20, 448 bytes long.
Data: <Thu mbe Wed mbe > 54 68 75 00 6D 62 65 00 57 65 64 00 6D 62 65 00
{45} normal block at 0x008E07B0, 1328 bytes long.
Data: <%a %b %e %H:%M:%> 25 61 20 25 62 20 25 65 20 25 48 3A 25 4D 3A 25
{44} normal block at 0x008E3D48, 344 bytes long.
Data: <PM Wed M:% > 50 4D 00 CD CD CD CD CD 57 65 64 00 4D 3A 25 00
{43} normal block at 0x008E3BC8, 320 bytes long.
Data: <C Sun > 43 00 CD CD CD CD CD CD 53 75 6E 00 CD CD CD CD
Object dump complete.


I can fully assure that the word 'new' doesn't appear in anything I've typed since all I have is the WinMain function, so where is this stuff coming from?

Share this post


Link to post
Share on other sites
Sfpiano    126
Well is there anything I can do about it, because when I get my full program switched over I'll have no way of knowing which ones are my files and which ones aren't.

Share this post


Link to post
Share on other sites
Fruny    1658
Quote:
Original post by Sfpiano
Well is there anything I can do about it, because when I get my full program switched over I'll have no way of knowing which ones are my files and which ones aren't.


I don't know.

For what it's worth, this is not a leak - it's just memory that gets released after the object dump (hard to do a dump when you've shut down your IO library, isn't it?)

Share this post


Link to post
Share on other sites
Sfpiano    126
So you're saying if I get output like this:

Dumping objects ->
{60} normal block at 0x00C5AA30, 1024 bytes long.
Data: <( l m > 28 85 C5 00 6C 85 C5 00 6D 85 C5 00 B0 0F C5 00
{59} normal block at 0x00C59460, 5520 bytes long.
Data: <P INDOWS\syste> 50 95 C5 00 49 4E 44 4F 57 53 5C 73 79 73 74 65
{56} normal block at 0x00C57B28, 5496 bytes long.
Data: < { > A8 7B C5 00 B4 85 C5 00 B5 85 C5 00 A0 0F C5 00
{54} normal block at 0x00C57018, 2768 bytes long.
Data: < p ocuments and> 98 70 C5 00 6F 63 75 6D 65 6E 74 73 20 61 6E 64
{52} normal block at 0x00C51278, 1056 bytes long.
Data: < | > 20 00 00 00 00 00 00 00 94 EB 90 7C 00 00 00 00
engine.cpp(183) : {50} client block at 0x00C53FB8, subtype 0, 4 bytes long.
Data: < > CD CD CD CD
{49} normal block at 0x00C53F70, 12 bytes long.
Data: <0bJ > 30 62 4A 00 CE CD CD CD 10 00 00 00
{47} normal block at 0x00C50F20, 792 bytes long.
Data: <September > 53 65 70 74 65 6D 62 65 72 00 CD CD CD CD CD CD
{46} normal block at 0x00C50D20, 448 bytes long.
Data: <Thu mbe Wed mbe > 54 68 75 00 6D 62 65 00 57 65 64 00 6D 62 65 00
{45} normal block at 0x00C507B0, 1328 bytes long.
Data: <%a %b %e %H:%M:%> 25 61 20 25 62 20 25 65 20 25 48 3A 25 4D 3A 25
{44} normal block at 0x00C53D48, 344 bytes long.
Data: <PM Wed M:% > 50 4D 00 CD CD CD CD CD 57 65 64 00 4D 3A 25 00
{43} normal block at 0x00C53BC8, 320 bytes long.
Data: <C Sun > 43 00 CD CD CD CD CD CD 53 75 6E 00 CD CD CD CD
Object dump complete.


the only thing that's an actual problem is the one that has a .cpp file attached to it?

Share this post


Link to post
Share on other sites
Fruny    1658
Quote:
Original post by Sfpiano
the only thing that's an actual problem is the one that has a .cpp file attached to it?


The rest come from code which doesn't contain debug information (so all it can give you is an address). Third party libraries. There could be a leak in there, but I'm just mentioning that the IO library is often thought to leak when in fact it just cannot release its memory until after the object dump.

I am sure the difference between "normal block" and "client block" is documented somewhere. If you want to learn more about the issue, that's probably what you should start looking for.

Share this post


Link to post
Share on other sites
Sfpiano    126
Fluid's memory manager tells me I have 5 memory leaks but it says they're at ??(00000)::?? I've also tried using _NORMAL_BLOCK, and it tells me that there are also 5 memory leaks, but it says they originated in crtdbg.h in the new function which doesn't really help me.

[Edited by - Sfpiano on March 29, 2005 3:54:26 PM]

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Fluid Studios' code can only detect allocation owner via macro hackery - external libraries fall through the net. I have written an improved tracker that determines owner via call stack and debug information; this may point out your problem.

Quote:
There could be a leak in there, but I'm just mentioning that the IO library is often thought to leak when in fact it just cannot release its memory until after the object dump.

There is a solution :) 1) generate report via debug output, Win32 CreateFile (with static buffer), or something else that doesn't require init/allocation. 2) regenerate on every free() once shutdown has started (e.g. after a non-local static object set up for the purpose is destructed). This guarantees accurate results.

Share this post


Link to post
Share on other sites
chollida1    532
The microsoft crt debugging tools allow you to take a snap shot as a starting point. Usually you do this in your winmain.

When you exit you can then dump the leaks at the same point and you shouldn't have near as many false positives.

CHeers
Chris

Share this post


Link to post
Share on other sites
Sfpiano    126
I tried calling _CrtMemCheckpoint(NULL) as the very first thing in WinMain and calling _CrtDumpMemoryLeaks() as the very last thing in WinMain, but it just tells me that all of these leaks are originating from crtdbg.h in the new function.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this