CODEWITHSUNDEEP
visual-studio-2008memorymemory-leaks
Marin
Marin

Reputation: 1331

_CrtDumpMemoryLeaks truncated output?

I am trying to use Visual Studio's capability to detect memory leaks, but I keep getting truncated output, like:

Dumping objects ->
{174} normal block at 0x0099ADB8, 48 bytes long.
 Data: <h:\najnovije\tru> 68 3A 5C 6E 61 6A 6E 6F 76 69 6A 65 5C 74 72 75 
{170} normal block at 0x0099AD58, 32 bytes long.
 Data: <h:\najnovije\tru> 68 3A 5C 6E 61 6A 6E 6F 76 69 6A 65 5C 74 72 75 
Object dump complete.

What am I doing wrong? I added 

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

to the beginning of my code.

Thank you.

Upvotes: 0

Views: 416

Answers (3)

Ben Harper
Ben Harper

Reputation: 2580

If you want source file + line number of where the allocation took plane, then you must use the CRT debug alloc functions instead of regular malloc/new.

If you're using 'new' then you can do this: #define new DEBUG_NEW

Or for malloc, use _malloc_dbg instead of malloc. Just read the MSDN docs for _malloc_dbg and you'll see various items there. Most macros that use this will use __FILE__ and __LINE__ here.

Upvotes: 2

Peon the Great
Peon the Great

Reputation: 1319

This output is not truncated. It's meant to be used in another way.

Try give a deeper observation to your program. You can find Visual Studio always (more precisely, ~99% of the time) gives you same leaking address 0x0099ADB8 and 0x0099AD58, if you use same test steps.

Now, you need to setup data breakpoints that break on changes of these two addresses. Break at the beginning of your program, select Debug->New Breakpoint->New Data Breakpoint, type in the address. In your case, you need to create two of them: one for 0x0099ADB8 and the other for 0x0099AD58. Then eventually you will be stopped at the code that instantiate this block of memory, which gives you exactly the point where the leak is from.

There can be cases that you got different leaking address every time. In that case, you'd better use gflags and WinDBG instead so that you will have a chance to diff the memory contents and start from there.

Upvotes: 1

Patrick
Patrick

Reputation: 23619

Unfortunately, Microsoft Visual C++ does not tell you the exact place of the leak. And even if it would, it would probably be somewhere in some generic routine of your application (like AllocateString) or in the new operator.

In your output h:\najnovije\tru is not the [truncated] name of a source file that caused the leak, but it's the first 16 bytes of the data block that was not freed.

Try looking for places where you store a filename in your application. This will probably point you to the actual leak.

Upvotes: 2

Related Questions