No you aren’t doing anything wrong… the code is just (edit: I removed my flaming since I was wrong in my assumptions when I wrote this post)
I see whats going on I’ll have this fixed, well maybe not all the memory leaking but definately a large majority of it, for the release of COLLADA 1.4 DOM Patch 1 which will hopefully be released by the end of the day today.
Actually… Upon further inspection you are doing something slightly wrong.
dae::cleanup() is a static function and it is actually useless to call it from a non static context.
The proper way to exit your program would be to call
DAE* daeObject = new DAE;
delete daeObject;
DAE::cleanup();
-Andy
Heres further explanation if you care about these details.
The first line in cleanup checks the DAEInstanceCount. If it is not 0 then it will not delete the static meta information which is causing your leak.
In the destructor the DAEInstanceCount is decremented. That is why you must call it statically after you delete your pointer to the DAE object.
Thanks very much alorino as that solved this problem and it now cleans up properly when I instantiate and delete the object. My second problem is that I’m wondering how to clean everything up.
Unfortunately he’s right. It seems that the memory that the collection has allocated never gets released. I kinda debugged the COLLADA DOM and found out that DAE::unload() doest the same thing as daeDatabase:removeCollection(). The removeCollection code thou just removes the collection from the two vector arrays, but doesn’t free the memory that has been allocated from the previous create collection in the createCollection method. Now i hate to say this, but i didn’t find any reference counters that will delete the memory that a collection has allocated in DAE::cleanup(). As i found out, the right thing to do so that the memory leaks won’t show up is to get the collection pointer and delete itself. Which unfortunately has the really bad habit of deleting the elements, which leads to a crash in a later load when the DOM library tries to resolve all the elements with daeElement::resolveAll(), because they are deleted, but still in the static array of loaded elements.
I’m pretty sure that i’m not using the library in the intended way and probably have a really bad hacks that lead to my load crashes. But then again, i can’t seem to find them, wrote everything as it was in the programming guide but still trying to remove the memory leaks leads to a crash.
To be honest i’m still struggling with COLLADA DOM and will continue trying to overcome all of its problems, just because the library has the potential to be really good i really don’t wont to spend 2 months in writting my own DOM parser of COLLADA just because the one provided here has a few bugs that still need to be fixed. And i’ll do my best to feedback any information regarding the bugs i find, so that they can be fixed as fast as possible.
Most of the leaks were cleaned up a long time ago. I just ran valgrind on the DOM test program from the latest code in the Subversion repo on SourceForge. It reported one (smallish) memory leak in the .raw file test, which I fixed in revision 320. Now valgrind reports no memory leaks in the automated tests.
What leaks are you getting? What version of the DOM are you using?
My collada stuff resides in a dll (with multithreaded debug dll code generation flag)
The collada object is instantiated and destroyed within a global function scope (copies data from collada format to my format and destroys it)
the dll is used (imported) in a static lib project which is compiled with multithreaded debug flag
this static lib is then used in the .exe project which is compiled with multithreaded debug flag. It is here i use the crt dump memory leaks function. I made sure that the dumping takes place after all destructors are called (atleast the exe part of it). I am not sure when the destructors of the dll are called, but I checked the breakpoint placed at the destruction of collada object got hit.
One more thing I just noticed…
When I first made the collada dll, for some reason (please explain this as well) my collada dll gave a warning
LINK : warning LNK4098: defaultlib ‘MSVCRT’ conflicts with use of other libs; use /NODEFAULTLIB:library
I ignored this and ran the application, but I got a pop-up window saying,
"Runtime error !
R6034
An application has made an attempt to load the C runtime library incorrectly "
When I use /NODEFAULTLIB flag, I get a ton load of error messages all related to unresolved external symbol from libcollada_dom_d.lib, libxml2 and others.
So, finally I got it working by not using /NODEFAULTLIB and by setting ignore library flag to MSVCRT.
I somehow assume by ignoring MSVCRT, the dumping of memory leaks is taking place. Please help !!!
DOM 1.2 is from Nov 06, so it’s pretty old. I believe that most of the memory leaks were cleaned up in DOM 1.3 (from March 07), and that the leaks are completely gone from the latest version of the code in Subversion.
I somehow assume by ignoring MSVCRT, the dumping of memory leaks is taking place. Please help !!!
I don’t think that’s the case. I’m pretty sure we use that same ignore command in some of our apps. I think the issue is mixing debug and release versions of the C runtime, and that the ignore command clears it up.