Fixing memory leaks
Fixing memory leaks
Hello,
I am using Irrlicht for a DLL plugin, and I get some weird memory leaks error when I close the program which has loaded the DLL.
I would like to know if there's a way to clean up everything correctly (I don't know how to do that to ITriangleSelector, IMesh,...)
Here's the paste, it contains mostly OctTreeSelector I haven't cleaned up.
(Warning, BIG SIZE AHEAD !!)
http://www.mediafire.com/?mwzmgym4xmz
Thanks.
I am using Irrlicht for a DLL plugin, and I get some weird memory leaks error when I close the program which has loaded the DLL.
I would like to know if there's a way to clean up everything correctly (I don't know how to do that to ITriangleSelector, IMesh,...)
Here's the paste, it contains mostly OctTreeSelector I haven't cleaned up.
(Warning, BIG SIZE AHEAD !!)
http://www.mediafire.com/?mwzmgym4xmz
Thanks.
You should read the documentation about IReferenceCounted.
Everything you create with a function that starts with 'create' for example createDevice must be drop()ed when you no longer need it.
The things you get with get, add, or whatever methods must not be dropped because they are handled by the engine.
Everything you create with a function that starts with 'create' for example createDevice must be drop()ed when you no longer need it.
The things you get with get, add, or whatever methods must not be dropped because they are handled by the engine.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
Mmm Ok I've dropped the triangleSelector of my plane, now it shows
irrXML... I've already deleted it once I finished to parse an XML file !
Is there another way to clean it up ? Can I ignore that memory leak or it's dangerous ?
Thanks.
Code: Select all
Detected memory leaks!
Dumping objects ->
{10238} normal block at 0x0D866C08, 432 bytes long.
Data: < A A> 00 00 20 C1 00 00 00 00 00 00 20 41 00 00 20 41
.\CSceneManager.cpp(1500) : {10237} client block at 0x0CFDA1D8, subtype 0, 44 bytes long.
Data: <H 5 \ 5 @j l > 48 9E 35 04 5C 9E 35 04 40 6A 86 0D 08 6C 86 0D
.\irrXML.cpp(86) : {7675} client block at 0x0CF99FB8, subtype 0, 16 bytes long.
Data: < *6 69 > 00 2A 36 04 C8 36 39 04 B4 06 00 00 01 CD CD CD
Object dump complete.
Is there another way to clean it up ? Can I ignore that memory leak or it's dangerous ?
Thanks.
You can ignore them but you shouldn't.
When the program is ended the OS frees all the memory that was allocated by it. However while your program is running it could happen that some things which are created more than one time will eat up all memory of the system. Best example is firefox. Surf some hours with it and it takes 1Gig of RAM and still wants to eat more.
When the program is ended the OS frees all the memory that was allocated by it. However while your program is running it could happen that some things which are created more than one time will eat up all memory of the system. Best example is firefox. Surf some hours with it and it takes 1Gig of RAM and still wants to eat more.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
I fixed for the last scene manager, I have to drop the triangleSelector each time I don't need it, I understand now the ->drop() usage.
But isn't there a problem with irrXML's memory ?
I'm sure that I removed it after the while(xml && xml->read()) loop, with delete xml;
Line 86 points to the XML creator...
And here's it's destructor :
Thanks.
But isn't there a problem with irrXML's memory ?
Code: Select all
Detected memory leaks!
Dumping objects ->
.\irrXML.cpp(86) : {7675} client block at 0x0D129FB8, subtype 0, 16 bytes long.
Data: < *K 6N > 00 2A 4B 04 C8 36 4E 04 B4 06 00 00 01 CD CD CD
Object dump complete.
Line 86 points to the XML creator...
Code: Select all
IRRLICHT_API IrrXMLReader* IRRCALLCONV createIrrXMLReader(const char* filename)
{
return createIrrXMLReader(new CFileReadCallBack(filename));
}
Code: Select all
//! destructor
virtual ~CFileReadCallBack()
{
if (Close && File)
fclose(File);
}
Well you have to do something like this:
The line number in the visual studio output just shows where the data has been allocated.
One of the useful things in this output is the number in the {}. In this case 7675. It tells you that the data is the 7675. block of data that has been allocated by your program. So you can call CrtBreakAlloc(7675) as the first thing in your main or WinMain function and the Debugger will break when the block is allocated. Then you have a full call stack and can trace the location where the data is being initialized.
Code: Select all
IrrXMLReader* xml = createIrrXMLReader("somefile.xml");
// Parse the file
delete xml;
One of the useful things in this output is the number in the {}. In this case 7675. It tells you that the data is the 7675. block of data that has been allocated by your program. So you can call CrtBreakAlloc(7675) as the first thing in your main or WinMain function and the Debugger will break when the block is allocated. Then you have a full call stack and can trace the location where the data is being initialized.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
after changing from a release to debug .dll I was faced with about 26 memory leaks, nearly all came from meshManipulator->createMeshWithTangents, I had one scene::IMesh* tangentMesh; which I used 24 times and only dropped it once, so that didnt work, the other two or so leaks came from undropped rotation animators, xml should be dropped, well all stated above. Basically you can search for create and make sure each create something method gets its drop and you'll be fine...