Collada DOM memory leak issue.

Other Standards COLLADA
21

thanks for the prompt reply!

i am using .net 2005. the leak is 24 bytes as reported by CRT debug info.

i will try to add the source into my solution so i can trace it and let you know what exactly is leaking.

22

I’m using this as my test program:

#include <dae.h>

int main() {
	DAE* dae = new DAE;
	delete dae;
	DAE::cleanup();
	return 0;
}

(Again, the DAE::cleanup isn’t necessary, but I wanted to be consistent with what you were doing). Neither Valgrind nor VS 2005 report any memory leaks for me with this code, in either debug or release mode. I’m a bit stumped about how to reproduce this… you’re sure you’re not using old libs or anything? And that the memory leak is coming from the DOM?

i am using .net 2005. the leak is 24 bytes as reported by CRT debug info.
Just to make sure, you don’t need to turn on anything special to get leaks reported in VS, right? Just running the program under the debugger should report leaks?

Steve

23

I include these in my main.cpp

// header files for debuging memory leak:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

then put these lines in your main():

// enable memory leak check
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF |   _CRTDBG_CHECK_EVERY_1024_DF);

these should give you leaks…

24

Thanks, I get the leak report now. Unfortunately the report doesn’t say anything about where the leak comes from, even though I know I have debug symbols setup properly because I can step into the DOM in the debugger. I’m not sure how to track this down, but I’ll keep thinking about it. If you have any ideas be sure to let me know.

25

Just an FYI, the CRT dump memory leaks will report STL global variables , global class objects that have instantiation and destruction(I think) as memory leaks.

26

there are a lot of leaks once you load a file with a DAE object too. maybe there are better tools under Linux for you to track them down?

27

Thanks for the info. The leak report could be bogus I guess, or from something other than the DOM (like the STL, which the DOM uses).

I don’t get any additional leaks when I load a file. I get the same 24-byte leak report. I’m using a debug build of VS 2005, linking against the DOM statically. Let me know if there’s anything else I need to do to see the additional leaks.

That’s the interesting thing: valgrind doesn’t report any leaks. The only thing I can think to try is using a different memory leak detector on the Windows build.

28

this leak detector might help?
http://dmoulding.googlepages.com/downloads

i couldn’t get it to work with vista, it should work if you use windows xp.

29

Thanks for the tip. I’ll try it out tomorrow.

30

That leak detector worked pretty well. It gave me a call stack so I was able to track down the problem. There’s a small leak in the libxml function __xmlGlobalInitMutexLock. A CRITICAL_SECTION object is allocated and never freed. I’ve reported the bug. In the meantime, I don’t think this should be a show-stopper. It’s a single 24-byte leak. It only occurs once in your app. If you have any other leaks you’d like me to look at, be sure to let me know. As I mentioned, I don’t see any other leaks.

Just for the record, both Microsoft’s leak detector and valgrind were right: on Windows there’s a 24-byte leak in libxml, but on Linux there is no libxml leak because different code is executed.

Steve

31

glad you found the problem!

I did get quite lot of other leaks after I do this:

pCollada-&gt;load(url);
domCOLLADA *dom = pCollada-&gt;getDom(url);
dom-&gt;resolveAll();
DeIndex(pCollada);
// Load all the image libraries
for ( u64 i = 0; i &lt; dom-&gt;getLibrary_images_array().getCount(); i++) {
    ReadImageLibrary( dom-&gt;getLibrary_images_array()[i] );			
}
delete pCollada;

DeIndex() and REadImageLibrary() code are from COLLADA_RT sample.

have you run VLD on all your test programs?

32

I did get quite lot of other leaks after I do this
Yeah, RT is leaky as hell. I just filed a bug on this yesterday in fact. Based on the leak report attached to that bug I get the impression that all the ReadWhatever functions leak memory.

Unfortunately our RT developer is on vacation for the rest of the year. I’m hard at work on a DOM 2.0 release and I’m not in a position to fix these leaks now. I might be able to look at it sometime, but I can’t make any promises. It shouldn’t be too hard to fix these yourself if you’re so inclined.

have you run VLD on all your test programs?
No, just on my little sample program that I used to track down the libxml leak. Frankly, VLD is a pain to use because it requires modifying your source, so I’ll probably only use it if someone reports a leak that I can’t catch with Valgrind. Valgrind reports no leaks on our automated test suite, which exercise the DOM pretty well, so I don’t think there are many (any?) DOM leaks anymore.

Steve

33

any update on possible fix that might be coming up regarding this [in any future release] ?

34

Are you talking about the RT memory leaks? I believe our RT guy is working on fixing them now. If it’s a big problem for you, keep in mind that they should be fairly easy to fix yourself.

Steve