Memory Leaks on console but not in OgreLeaks.log

[rincewind]

Hi,

I'm currently trying to fix memory leaks in our application. After fixing everything in OgreLeaks.log, I now get the "Congratulations"-Message in the OgreLeaks.log but still the following output on the console in Visual Studio:

Code: Select all

Detected memory leaks!
Dumping objects ->
{60836} normal block at 0x1D4DA430, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60824} normal block at 0x1D4DA368, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60812} normal block at 0x1D4DA2A0, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60329} normal block at 0x1D4C8C78, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60315} normal block at 0x1D4C8BB0, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60301} normal block at 0x1D4C8AE8, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60068} normal block at 0x1D47E2D8, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60054} normal block at 0x1D47E210, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
{60040} normal block at 0x1D47E148, 140 bytes long.
 Data: < yp            ?> 14 79 70 0F 00 00 00 00 08 91 A2 00 00 00 80 3F 
Object dump complete.

Do I still have leaks (which I assume from that output)? Can I somehow get them to be output into the Leaks-Log file together with the additional info?

I would be very grateful if someone can shed some light on this:

Greetings,

Rincewind[/code]

[sinbad]

OgreLeaks.log will only report leaks from OGRE code, or code which uses OGRE's memory manager. Additional leaks may exist elsewhere that it can't pick up.

[rincewind]

Ok, but where does the report on the console come from then? I thought it was from Ogre, too.

Rincewind

[sinbad]

It's not Ogre. Looking at it again, it might be the DirectX debug runtime. Unfortunately the output it produces is supremely unhelpful - much less helpful than our memory leak tracker. God knows where to start looking for those. Hmm, 0x1D47E2D8 eh? I know it well...

[monster]

From MSVC, usually you have to enable it, with something like;

Code: Select all

_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF|_CRTDBG_ALLOC_MEM_DF);
_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_ASSERT,_CRTDBG_FILE_STDERR);

[rincewind]

Ok, thanks a lot for your help, now on to some very nasty debugging session

[monster]

Or, if you dump the leaks manually by calling

Code: Select all

_CrtDumpMemoryLeaks();

There is a way to get it break on the allocations reported via the number in brackets just before it says 'normal block', but I can't remember what that is!

Hang on...

[monster]

Ah, yes, to get it to break on (for example) the first reported leak in your output you'd do;

Code: Select all

_CrtSetBreakAlloc(60836);

Beautiful!

[leedgitar]

Doesn't look like a DirectX memory leak (at least...not DirectX9). I actually used to think the DX memory leaks were worthless, until I did some googling; determined to find a way to actually use the info . The DX memory leaks include an lAllocID for each item that was leaked. In the DX control panel, you can enter in the lAllocID into the box that says "Break on AllocID". When you run again, it will create a user breakpoint and stop at the spot of allocation, such as creating a device, vertex buffer, etc. I assume that behind the scenes, it uses what monster describes above.

I just did this recently because it appears that Managed DX does not always destroy all resources, even when you explicitly dispose of them.

[klepto]

A useful alternative to coding

_CrtSetBreakAlloc(60836);

is to view this expression in a debugger watch window:

{,,msvcr71d.dll}_crtBreakAlloc

then you can set the value in the watch window (i.e. to 60836) and stop on different memory allocations without recompiling.

Check http://msdn.microsoft.com/library/defau ... number.asp for more info.