Getting Irrlicht to report memory leak source info?

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!
Post Reply
Castaa
Posts: 39
Joined: Mon Jul 07, 2008 7:38 pm
Location: San Francisco
Contact:

Getting Irrlicht to report memory leak source info?

Post by Castaa »

We are using the debug version of the Irrlicht.dll. We are compiling it our self. It's working fine but we have memory leaks somewhere in the irrlicht code. (Note: this is our problem and probably not an irrlicht bug)

How do I get irrlicht report the source file and line number of the leaking memory that is dumped on exit of our app in debug mode in Visual Studio?

Thanks.


Our leaking dump looks like this. I thought irrlicht was setup to report memory leaks including the source file and line number where the allocation occurred.

example:
{2254} normal block at 0x002EED00, 1104 bytes long.
Data: < \7 @]7 > D4 5C 37 10 40 5D 37 10 00 00 00 00 00 00 00 00
My game: Star Sonata
Star Sonata is a massively multiplayer space game.
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

The easy way would be to run your application under the debugger. Step into main(), open up the watch window, and add a watch on the variable _crtDebugAlloc. Set the value of _crtDebugAlloc to 2254, and then run the application. The debugger will stop when the problematic allocation is being made. Then look at the stack and see what function was allocating the memory.

Travis
Castaa
Posts: 39
Joined: Mon Jul 07, 2008 7:38 pm
Location: San Francisco
Contact:

Post by Castaa »

vitek wrote:The easy way would be to run your application under the debugger. Step into main(), open up the watch window, and add a watch on the variable _crtDebugAlloc. Set the value of _crtDebugAlloc to 2254, and then run the application. The debugger will stop when the problematic allocation is being made. Then look at the stack and see what function was allocating the memory.

Travis
Thanks Travis for the tip. Sadly my leak appears to be related to the VideoDriver object's reference counter being grabbed more times than it's dropped as my app shuts down and exits. Thus it's never deleted on exit and a bunch of objects that driver object has allocated doesn't get deleted as well. So I have a ton of objects reported as leaking. Therefore it's not as simple at looking up one leak.


There should be a way for it directly output the source file and line in question. This is how our main code (non-irrlicht) outputs leaks.

example of a leak output in our code:
.\main.cpp(44) : {438} normal block at 0x0029AE20, 1 bytes long.
Data: < > CD
Last edited by Castaa on Fri Dec 11, 2009 8:02 am, edited 1 time in total.
My game: Star Sonata
Star Sonata is a massively multiplayer space game.
Castaa
Posts: 39
Joined: Mon Jul 07, 2008 7:38 pm
Location: San Francisco
Contact:

Post by Castaa »

#define CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)



I see the code in the irrlicht headers anyway.
My game: Star Sonata
Star Sonata is a massively multiplayer space game.
Castaa
Posts: 39
Joined: Mon Jul 07, 2008 7:38 pm
Location: San Francisco
Contact:

Post by Castaa »

I think I found my problem. That above redefinition a new for line number debugging of memory leaks was #defined out by another programmer on our team because it conflicted with other libraries were are now compiling into our modified version of Irrlicht.
My game: Star Sonata
Star Sonata is a massively multiplayer space game.
Post Reply