Collada DOM memory leak issue.

I am new to Collada/DAE and I am wondering if I am doing something wrong or if there are memory leaks in the DOM.

In my application I have the following:


DAE* daeObject = new DAE;
daeObject->cleanup()  // I have tried without this as well
delete daeObject;

There are a ton of memory leaks when I do this, am I supposed to shut down some other way?

Thanks!

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.

-Andy

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.


DAE* daeObject = new DAE;
daeObject->load( "file:///cube.dae" );
delete daeObject;
DAE::cleanup();

I get memory leaks as I guess cube.dae stays loaded. What do I have to do to clean up after this?

Thanks for your time.

me too, i have too many leaks, is it from collada or us?


DAE* dae = new DAE();
dae->load("test_tex.xml");
dae->unload("test_tex.xml");
delete dae;
DAE::cleanup();

I don’t see why DAE::cleanup() needs to be public or called. When I delete my last DAE object it should automatically clean up. Instead of:

DAE* daeObject = new DAE;
delete daeObject;
DAE::cleanup();

I’d prefer to:

{
DAE daeObject;
}

And have it all clean up when my object is deleted for going out of scope. I see no reason to have to call cleanup().

Cheers,

Rich

When I make a DAE::Cleanup(), the DAEInstanceCount is 0 and there is still leaks :’(

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.

COLLADA DOM bugs should be reported to the project’s bug tracker.

COLLADA DOM Bug Tracker

Thanks,
Marcus

I have the same problem, the static array (ResolveArray) is never freed. Do you find a solution ? It’s really annoying…

I propose a patch. First of all modify the cleanup() function :


void
DAE::cleanup()
{
	if (DAEInstanceCount == 0) {
		daeElement::releaseElements();
		daeMetaElement::releaseMetas();
		daeAtomicType::uninitializeKnownTypes();
	}
}

And add the new function to the daeElement class :


void daeElement::releaseElements()
{
	resolveArray.clear();
}

which is declared static.

It is simple but it works for me.

Hi,

I am getting memory leaks too !!
DAE:cleanup() had no effect !!
Was there any solution for this ???

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?

Steve

I use,

  • COLLADA 1.4.1 DOM 1.2
  • COLLADA schema version: 1.4.1 and 1.3.1

Here is my setup if it helps,

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.

I have used the following installer
COLLADA_DOM_FX_RT_1.3.0_VC8.exe

But looks like the readme file inside it says
"

  • COLLADA 1.4.1 DOM 1.2
  • COLLADA schema version: 1.4.1 and 1.3.1
    "

So I am quite unsure what “latest version” means ??

It’s a misprint in the readme.

i am getting a leak with code as simple as:

DAE* pCollada = new DAE;   
delete pCollada;
DAE::cleanup();

this is with the latest code from SVN, build as a static lib.

Where specifically is the DOM leaking? What platform are you running on? What leak-detection tool are you using?

Also, just fyi, you don’t need to call DAE::cleanup yourself. It’s called automatically when the last DAE is destroyed.

Thanks,
Steve