Tons of Memory Leaks in Leadwerks?

[Ma-Shell]

When trying to use the guide below in order to use the CrtDbg Library for detecting memory leaks, I found, that it showed me leaks beyond count.

I then tried it on a fresh c++ project (created from the wizard within the Leadwerks-Editor), and noticed, that the leaks were there even on this new project.

 

The guide I followed:

http://msdn.microsoft.com/en-us/library/e5ewb1h3(VS.80).aspx

I noticed the includes and define were already in Leadwerks.h so the only thing one needs to do, is call the following line:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

 

Also, the Output sadly didn't show, in which files and line-numbers the memory got allocated (Although I defined "_CRTDBG_MAP_ALLOC" and tried various different things).

I therefore also tried Visual Leak Detector (http://vld.codeplex.com/). From what I saw, a lot of the memory seems to be allocated during various LW-functions, like the context-syncing, loading of the map or rendering, etc.

 

Did I do something wrong? Do these tools maybe measure the memory too early?

 

What really bothers me is that I can't really check my own code for memory leaks this way, as I simply wouldn't find them amongst the ~2000 (the exact count varies) number of leaks that are already there.

Does anyone have a suggestion, what to do here?

 

P.S.: Visual Leak Detector worked fine with LW2.5

[bandrewk]

I am also experiencing this issue. Just a few from the top:

 

Detected memory leaks!

Dumping objects ->

{106971} normal block at 0x06CAE738, 36 bytes long.

Data: <ä¬w > E4 AC 77 01 00 00 00 00 00 00 00 00 00 00 00 00

{106970} normal block at 0x0093BD58, 36 bytes long.

Data: <ä¬w > E4 AC 77 01 00 00 00 00 00 00 00 00 00 00 00 00

{106969} normal block at 0x06CAE6B0, 76 bytes long.

Data: <ø¿Ç x¶“ ø½Ç ÐãÊ > F8 BF C7 06 78 B6 93 00 F8 BD C7 06 D0 E3 CA 06

{106968} normal block at 0x06CAE650, 36 bytes long.

Data: <ä¬w > E4 AC 77 01 00 00 00 00 00 00 00 00 00 00 00 00

{106967} normal block at 0x06CAE5F0, 36 bytes long.

Data: <ä¬w > E4 AC 77 01 00 00 00 00 00 00 00 00 00 00 00 00

....

 

If you want to see your own memory leaks simply search for ".cpp" inside the output window. Your memory leaks will look like that:

 

..\..\Source\MenuState.cpp(96) : {75115} normal block at 0x06D0AEB0, 100 bytes long.

Data: <œ1m $¬r > 9C 31 6D 01 24 AC 72 01 00 00 00 00 00 00 00 00

[Josh]

I've tested pretty extensively for leaks throughout the development process.

 

The Lua virtual machine will gradually build up memory until a certain threshold is reached and then run a garbage collection call. This can appear like memory is leaking when it isn't.

 

You can also call System::GetMemoryUsage() at any time to get the allocated memory. This function only returns an accurate reading with the Visual Studio compiler, and only is accurate with a Debug build.

[Ma-Shell]

Ah, that's pretty good news. So I can use the function to see whether there is some memory leak in a method that is called quite often (which is indeed the worst kind of memory leak ), but I can't see, whether I have allocated memory once and forgot to free it, or where the leaking memory was allocated, which makes troubleshooting really hard.

 

If you want to see your own memory leaks simply search for ".cpp" inside the output window.

It doesn't show any files/line numbers for me (even for the memory leaks I built on purpose for testing)... Did you only add the "_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );" or also any other defines? In case of the defines, it depends on, where it is done. Having a define of "_CRTDBG_MAP_ALLOC" before including Leadwerks.h leads to an error in the file "DetourTileCacheBuilder.h" (from LE), which defines some kind of free itself. Having it below this include doesn't show me the additional info. So what did you do for this to work?

 

 

EDIT: I guess, there is no possibility to disable LUA, is there?