I’m getting a heap corruption error in my COLLADA loader code, which I adapted from the integrationExample.cpp file in the DOM library. The crash occured in the freeConversionObjects() function. By process of elimination, I trimmed the code down to the following bare-bones snippet:
void LoadDaeFile(const std::string& filename)
{
DAE dae;
domCOLLADA* root = dae.open(filename.c_str());
std::vector<daeElement*> elts;
daeDatabase *db = dae.getDatabase();
//db->typeLookup(domNode::ID(), elts); // Uncommenting this line triggers the crash
}
As the comment indicates, the code as written runs fine; if I uncomment the call to daeDatabase::typeLookup(), I get a heap corruption crash when the function returns. Is there some sort of cleanup step I’m missing here?
Possibly-relevant details about my development environment:
COLLADA-DOM 2.2
Visual C++ 2008 Express Edition
Windows XP
The DAE file in question is just a basic cube; I’ll attach it just in case, but the crash seems to occur regardless of the scene I use, so I don’t think it’s anything to do with the data.
You’re right; the file I posted has a few syntax errors. Given the simplicity of the code that’s crashing, though, I’d be very surprised if such minor issues would produce memory corruption, rather than a well-defined error condition.
In any case, the syntax errors in cube.dae are irrelevant, as I posted the wrong scene :?. There was a file being loaded earlier than the ones I was testing, and that’s the one that was causing the crash. This scene is the Collada logo scene from the Test Model Bank (COLLADA Overview - The Khronos Group Inc – also attached below). This file passes the coherency test with no errors. I’m not at my test machine right now, so I can’t verify that the crash occurs with other files until a little later today.
If you are linking against the dll version of the collada dom library then check which version of the c runtime your application and the collada dom are loading. Now MS use side by side assemblies for the runtime libraries you have to check for both the debug and release variants and the actual version of each one being used. In most cases they all have to match for things not to crash. Here is a useful tool for doing this.
Aha! My Collada DOM DLLs were linked against the DLL C runtime, while the rest of my application was using the static version. I can’t believe that slipped by me; I know just how tempermental Visual C++ can be when its assorted C runtime libraries don’t match up. I guess I’m used to any problems showing up as link errors, rather than cryptic runtime crashes. Thanks Roger!
One further gripe, if the DOM maintainers are listening: the obvious solution here would’ve been for me to modify the DOM’s linker settings to match the rest of my application. However, this proved prohibitively difficult (if not impossible). For this change to work, the DOM’s external libraries (boost, etc.) would also need to be rebuilt with the new linker settings, and some of these libraries (most notably PCRE) are missing the appropriate Visual C++ project files. I spent several hours unsuccessfully trying to recreate the project files from scratch, but was unable to entirely eliminate the resulting fatal link errors. I eventually determined that it would be easier to modify the linker settings for the rest of my application (and all of its external dependencies, and their dependencies, etc.) to match the DOM’s, rather than the other way around. The good news is that everything is working now, but this sort of inflexibility makes me a bit uncomfortable. It would be great if future DOM releases shipped with a working static-C-runtime configuration. If that’s infeasible, could we at least get all the project files used to build the DOM’s external libs, so we can make the appropriate modifications locally?