Memory Leaks

I tried to get the last version (1.4.1) of the DOM but I get tons of memory leaks ! I already had several ones on the previous versions but I made a patch to get rid of them. It’s not enough on the last version.

Do you have the same problems ?

Yeah I was getting a ton of memory leaks any time I did anything with the dom. See this bug I posted over at SourceForge.

Here’s a zip file that has all the files I changed to eliminate the memory leaks. If you search for “sthomas” in the files you’ll find the code I changed. Some of the fixes I wasn’t 100% sure about, so be careful.

My changes are based on the latest code in the svn repository, which has changed since the official 1.4.1 release. If you’re going to use my fixes you should first grab the latest code from the repository.

Also, my code incorporates your fix for a previous memory leak that’s described in the thread you linked to.

Thanks a lot !

I don’t understand why these bugs are opened for a so long time. I’ll check your code soon.

yeah, I’m sorry.

Its only me who works on and maintains the COLLADA DOM. And thats not the only thing I do here at work. So lots of bugs that aren’t really easy to track down sometimes take a while before I even attempt to fix them.

But when people like sthomas supply patches to fix them, that makes me happy :slight_smile: I will get his patch rolled into the project as soon as I can.


Well, I now have a problem with the getInput_array() function for a domTriangle element. It’s not due to the patch but to the SVN version.

shtomas, do you experience the same pb ?

No, I use domTriangles::getInput_array and don’t have any problems at all. What kind of problems are you having? I don’t think that code’s changed at all since the initial release of the dom, so I doubt the latest svn version broke that functionality.

do you store the return value of getInput_array(). It returns a reference to a daeTArray. You may be copying the array. And there might be a bug there. I dunno I haven’t seen problems with that before but it might be worth looking into.


That was it, when I just get the address of the array, it works well. The problem be in the copy constructor.

Why doesn’t the getInput_array() returns a reference like most of the other Collada functions ?

it does.

 * Gets the input element array.
 * @return Returns a reference to the array of input elements.
domInputLocalOffset_Array &getInput_array() { return elemInput_array; }
 * Gets the input element array.
 * @return Returns a constant reference to the array of input elements.
const domInputLocalOffset_Array &getInput_array() const { return elemInput_array; }

I’ll look into the copy constructor and try to see why it is broken now.
If you can file a bug on the SF project page with some more info that would be helpful.


I’ll fill it as soon as I can.

I’m experiencing new problems. No more memory leaks are detected but if I export a file and just after import it, I get an access violation. It seems that some pieces of static information are not well reseted. If I don’t do the export before the import I don’t have this problem.

I do DAE::cleanup() at the end of the export.

I did not have this problem with the version 1.4 patch 3 with my memory leak patch.

I could be wrong but I think you’re supposed to do that only after you’re completely done with the dom. So if you export, then call cleanup, then try to use the dom again, it’s likely you’ll have problems.

Having to call cleanup manually is error prone, but I’m not sure of a better way. Cleaning up global resources is a huge pain in C++.

Well, after I am done with a function I want everything to be clean as if nothing has happened.

Anyway, if I remove the DAE::cleanup() it’s even worse.

I’ve fixed the code so DAE::cleanup() removes all objects from the memory, including all the static objects.

You can grab the code from my iDisk. … 1.4.tar.gz

This fix is based on the SVN trunk revision 44.
Also fix the memory leak in daeURI caused by not freeing the string before assigning the new one.
I hope this fixes all memory leaks.

I tried your version and it crashed the first import. Have you only made changes for the dae::cleanup ?

I think it’s due to the fact that I was using revision 34.

Each time I update, a new stuff is buggy.

I’ve fixed several stuff actually. You can search for the word “Nus”, I think I marked all the changes I made.

I took the SVN 45 revision and I have the same problems : several Get Functions returning weird values.
I can’t test your changes, I’m sorry.
I was thinking it was maybe the baginning of a stable version but it’s even worse ^^

This might have been my fault.

The codegenerator has a bug in it. And SThomas had fixed some spots by hand where it failed (some things like domInstance_camera, domInstance_node) but I forgot to put those fixed lines back in after regenerating the code.

I will put those in and test these changes.


The original COLLADA doesn’t really care about the static objects. There are a lot of static objects that being constructed once and never being released even if I call DAE::cleanup(). For programming in consoles (in my case Wii, XB360, PS3), I must have a very clean memory. I hope the next release of COLLADA will address this problem…

Did the fix you posted on the forum fix all the static object memory leaks?

Are you using COLLADA for a delivery format for console games??
I sure hope not. But as part of the pipeline its probably using COLLADA DOM for a fast path loader for the engine before conditioning all the assets into your own format. Is that the case?

Also please respond to my p.m. asap. I am trying to create a new package to release any day now. To include your changes in that release I need to hear back from you.


Of course, I don’t include COLLADA in my engine.
But for my test programs, I usually include COLLADA and I have to know that if my program is leaking or not. For me, COLLADA is quite convenient for supplying data to my tests before making my own data.

>>Did the fix you posted on the forum fix all the static object memory leaks?
The fix that I posted fix all the static object memory leaks.