Memory leaks

I always test with leak detection (see test_feature) on so I find it hard to believe there is a leak in AngelScript. Though I'll investigate this, as no code is ever guaranteed to be bug free, no matter how much you test it.

Have you verified which memory allocation is leaking? Add a call to _CrtSetBreakAlloc(3179) to have the application break when the memory is allocated so you can see exactly what it is. The number corresponds to the number you see in the dump output.

Thanks for reporting it.

[edit] I just ran the samples/events with memory leak detection turned on and no leaks were detected. Of course, I'm using 2.8.1 WIP, so this is not ruling out any memory leaks in 2.7.1b. [/edit]

I added the extra call (I'm making a note of that call, it's great!)
and it "broked" :) here:

void asPushActiveContext(asIScriptContext *ctx)
{
asCThreadLocalData *tld = threadManager.GetLocalData(); <----------
tld->activeContexts.PushLast(ctx);
}

BTW, I put the same debug call in my little code but in my case the number was 627

_CrtSetBreakAlloc(627);

Detected memory leaks!
Dumping objects ->
{628} normal block at 0x003266B8, 4 bytes long.
Data: 78 65 32 00
{627} normal block at 0x003267E8, 24 bytes long.
Data: < f2 > B8 66 32 00 00 00 00 00 01 00 00 00 00 00 00 00
Object dump complete.

...and it took me to the same location in the script engine code.

Hope that helps.

-Steve

Quote:

I always test with leak detection (see test_feature) on so I find it hard to believe there is a leak in AngelScript.

I added the call to _CrtDumpMemoryLeaks(); at the end of test_feature project's main() function and got even more leaks than I originally told you about. By the way unless you call that function the output window doesn't automatically show any leaks.

I don't mean to be the bearer of bad news...

-Steve

You're not bearing bad news. :)

You've showed me why you think you're getting these memory leaks. But in reality they are not memory leaks.

The memory allocated in asPushActiveContext() is a one time allocation, and will only be freed after main() returns. You can free it yourself by calling asThreadCleanup() but that is only necessary if you're using multiple threads, in which case it should be called before each thread terminates.

You shouldn't call _CrtDumpMemoryLeaks() yourself, as it will dump all memory allocated at the moment it is called. This means that memory still referenced by global variables that are yet to be destroyed will show up as memory leaks (which is why you thought there were leaks).

Instead you should initialize the leak detection as follows:

#include <crtdbg.h>int main(int argc, char **argv){	_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF|_CRTDBG_ALLOC_MEM_DF);	_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_MODE_FILE);	_CrtSetReportFile(_CRT_ASSERT,_CRTDBG_FILE_STDERR);

The flag _CRTDBG_LEAK_CHECK_DF makes sure that the _CrtDumpMemoryLeaks() method is called at the very end of the application, i.e. after main returns and global variables have been destroyed.

Read up on these methods in msdn library. You'll learn some new and interesting ways to help detect memory leaks in your applications.

Thanks for clearing this up for me. I was worried there really were some leaks that I hadn't detected yet. :)

Regards,
Andreas

MSDN is where I got the information regarding making the call to see the allocated memory. Another article I read mentions to make that call at the end of main() in a console app. I guess they weren't exactly clear on the usage either. :)

Regardless, thanks for clearning that up about the usage of the C runtime functions. I'm used to MFC where all setup is handled for you. I'll start using the three methods you pointed out for all my Win32 apps.

Sorry for the scare and good job on catching any memory leaks! :)
-Steve

[Edited by - smjones on March 16, 2007 2:40:20 PM]