Access violation

I have downloaded the latest ColladaDOM from SourceForge and I’m getting this error on running my test app:

Unhandled exception at 0x00597859 in ColladaDom.exe: 0xC0000005: Access violation reading location 0xcccccccc.

The test app - from the wiki - is:

#include "dae.h"

int main(int argc, char* argv[])
{
	DAE dae;
	dae.add("sample.dae");
	dae.writeAll();
	return 0;
}

I have followed all the instructions on the DOM guide: Setting up - COLLADA Public Wiki wiki page regarding setup, the program compiles with no errors or warnings, but throws when running. It seems to be failing here (in dae.h):

	DAE(daeDatabase* database = NULL, daeIOPlugin* ioPlugin = NULL)
	  : atomicTypes(*this),
this line-->	    baseUri(*this, cdom::getCurrentDirAsUri().c_str())

I’m using Visual Studio 2005 (SP1) 8.0.50727.762 (SP.050727-7600) and I’m using the static library.

Does anyone have any thoughts? I’m scratching my head on this one :o)

EDIT: If I use the DOM_DYNAMIC pre-processor define I get this error:

Unhandled exception at 0x7c812a5b in ColladaDom.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012f4f8.

I’m aware of a few different problems with the Visual Studio support in the DOM 2.0 files I put up on Sourceforge. I’m hoping to fix those problems this week. You’re configuration and version of Visual Studio is pretty much the same as the one that I have on my machine though, so I feel like everything should just work.

Do both debug and release crash? You’re linking against libcollada14dom20-sd.lib in your debug build and libcollada14dom20-s.lib in the release build, right?

I went ahead and built a test app in VS 2005 using the same sample program that you have. When I first tried to build debug I got a warning about conflicting lib msvcrt, which I ignored. When I ran the program I got a startup error about it missing msvcrt80.dll, so I went back and added msvcrt to the “Ignore Specific Library” line in the linker settings. After that it ran fine. Release worked fine without any special modifications. I’ll add the note about msvcrt to the setting up guide on the wiki.

Regarding DOM_DYNAMIC, you only want that if you’re linking to the DOM dll, which it doesn’t sound like you’re doing.

I uploaded my test project in case you want to look at it to see if there’s any discrepancy between my settings and yours. I’m hoping you have something set incorrectly but with all the problems I’ve been having with Visual Studio lately it wouldn’t surprise me if there’s something wrong with the way the DOM is built.

Anyway please get back to me and let me know if any of this helps.

Steve

I’ve an Unhandled exception too when I try to open a document. And if I use the debug version of the dll the program cannot be initialised. Maybee manifest problem ?

(I’m using vc9 express, and the last vc9 build from sourceforge)

Other question, why the “getting started” use of a daeElement* and not domCollada* ?

I have rebuild the debug dll from svn trunk and now I can look where the bug appear :

DAE::charEncoding DAE::getCharEncoding() {
	return localCharEncoding.get() ? *localCharEncoding : getGlobalCharEncoding();
}

I believe so, yes. With the DOM 2.0 release I had the VC9 build linking against third party libs that were built with VC8. That worked fine on my machine since I had VC8 installed, but is a bad idea in general because your app would then be dependent on both the VC8 and VC9 runtimes. In the trunk I’ve provided third party libs built with VC9 and I think that will help solve some problems. I’ll be doing a 2.1 release shortly that has this fix, but in the meantime you should be working from the trunk.

I have rebuild the debug dll from svn trunk and now I can look where the bug appear
I don’t believe there’s anything wrong with that code. I just added a test for the char encoding setting to domTest. It runs fine on my box at home running Linux. I’ll check in VC9 Express when I get in the office tomorrow but I think the test will pass fine and won’t reveal what the problem is.

I still feel like this is a build setup issue, not a bug in the code. Can you run either the debug or the release versions of domTest successfully (‘domTest -all’)?

Steve

Yes all test pass. But maybee its a problem of used vc library ? Because the crash have no sense.

Other question, why the “getting started” use of a daeElement* and not domCollada* ?
In general if I don’t have a specific need to use a dom* class I prefer to use daeElement. I discuss this issue a bit in both the creating documents and importing documents sections on the wiki. Here’s a quote from the creating documents section:
Which method to use, the daeElement interface or the dom* classes, depends entirely on the context of what you’re trying to do. Sometimes one method is clearly easier to use (i.e. less code) than the other. Working with the dom* classes will be more efficient because no string conversions need to be done. In general I tend to use whatever method is easier to code.

Yes all test pass. But maybee its a problem of used vc library ? Because the crash have no sense.
All tests path in both debug and release? I feel it must be an issue in your build setup then. Are you linking against the DOM static lib or the dll?

release and debug test pass. I use the dll version. But I’ve not tried my project in release mode.

There is only somes minors project options that differe from the dom collada test project.

There has to be some reason domTest runs fine but your app doesn’t. Look very closely to make sure your app’s project settings match the domTest settings. Use the setting up guide to double check that everything is as it should be.

If you post your test app somewhere, or email it to me at x@y (x = steven_thomas, y = playstation.sony.com) I could take a look.

Mouarf… Its very strange. Srry for the mistake :wink: but apparently, in my apps, I have a 4 view (like 3d modeling software) set by default. If I put it in single perspective view the DAE::open works fine…

This is very very strange because the bug appear only in this case, so I think my 4 view system must corrupt something.

Thank you for your support and reactivity.

Hum, apparently its again a problem of my memory manager cause it works fine in release mode…

Collada dom dont like it :frowning:

Ok I’ve found the problem. I’ve rebuild a second time the library from the svn source and work fine this time. I think its because I’ve mixed zip sourceforge version of the file headers with the svn compilation. In other way I’ve missed to replace VC headers directory by the new.

Sorry for the annoyance and thank you for your support.