🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Memory leaks
Author
I discovered two leaks from library 2.7b. I have not tried detecting them in the latest version. You can duplicate see the leaks in the sample application "Events" which is found at ..\\AngelScript\angelscript_2.7.1b\sdk\samples\events\.
I had followed the tutorials very carefully to develop some little test apps for myself but I was not trying to detect any leaks. My apps ran fine. Well recently I decided to add leak detection by adding these lines at the top of main.cpp:
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
and calling
// Must call this to be able to dump any memory leaks to the Output window
#ifdef _DEBUG
_CrtDumpMemoryLeaks();
#endif
At the end of main() to display any leaks to the output window.
Well to my amazement I saw these leaks:
...
Detected memory leaks!
Dumping objects ->
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {3180} normal block at 0x009A48F0, 4 bytes long.
Data: <hZ > 68 5A 9A 00
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {3179} normal block at 0x009A5CB8, 24 bytes long.
Data: < H > F0 48 9A 00 00 00 00 00 01 00 00 00 00 00 00 00
Object dump complete.
The program '[2136] events.exe: Native' has exited with code 0 (0x0).
I got the same exact 4 bytes then 24 bytes in my home rolled sample apps. I believe the culprit is somewhere around asCreateScriptEngine::Build() because in my sample application I trimmed down the app to only creat the engine, load a script, then build then release the engine. I couldn't find any issues with the loading function so I think its the Build function. I'll continue to dig down to investigate but I thought I'd bring this up.
-Steve
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]
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]
Author
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: <xe2 > 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
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: <xe2 > 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
Author
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:
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
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
Author
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement