Access Violation in Collada .dll

Hi, I’m a CS student working on integrating collada dom loading into an existing graphics engine for school. When I walked through the original tutorials, everything was fine, but yesterday I attempted to test out loading the eagle.dae example, and I encountered an access violation in the .dll.

So the code:

DAE *collada_dom = new DAE();

daeInt error = collada_dom->load("../../Assets/Art Assets/Eagle.dae");

Causes an exception to be thrown (usually an access violation, but not always). By experimenting some, I found that almost any call to the collada dom threw an exception (such as collada_dom->setIOPlugin(NULL)). I tried recompiling the dom (for vc8, giving me libcollada141dom13.dll), but to no avail. I tried re-downloading it and using the windows installer, but still no change. I tried downloading the most current from svn and still it doesn’t work. (I’ve tried living without it too)…

At this point I’m just aggravated because I’ve spent a week correcting non-compiling examples only to have the library fail me. Note also that the error is reproducible, when I work at school I use a different project and .dll and it still happens. What can I possibly do now?

Ouch, I’m sorry to hear the DOM is giving you a hard time. Usually the type of problem you’re seeing is due to a problem in the project settings of your app, like linking to the wrong version of the C runtime.

Here are some things to try. I recommend you use the latest code from the Subversion repo on SourceForge.
(1) In the samples/export folder of the DOM is a sample exporter that uses the DOM. It can be built to use the DOM as a static lib or as a DLL. Try building the DLL version and see if that runs. If it does, there’s probably something wrong in your app’s project settings.
(2) Does your app work if you link against the DOM statically? (Remember to remove DOM_DYNAMIC from your projects #defines).

Steve

Well, I’m pretty sure that the problem is in my project settings since it was working last week, but broke just yesterday. That said, I have no idea how a change in the project settings (assuming that I’m still using the same IDE/compiler as last week) can affect the DLL so drastically.

  1. I tried using the latest build from .svn, but there’s a confliction in the LIBs. As in when I replace the “libcollada14dom13.lib” with “libcolladadom13.lib” and the “libcollada_dom.lib” with the new version, there’s a linker error specifying that about 14 functions are never defined. However, they appear to be defined in “libcollada_dae.lib” (which the newest version does not generate). Attempting to use the existing version of “libcollada_dae.lib” causes the reverse to happen, now 3 functions are being re-defined. At that point I pretty much gave up on trying to build/use the latest. Maybe I’m just totally misunderstanding something about static vs. dynamic loading as I’ve never built libraries before.

I tried using the example in the most resent version, but since I’m compiling at school, I can’t depend on Visual Studio 2005 finding the proper includes/libraries from the installation of collada dom, so I had to modify the project to look for them locally. Fortunately, that example corrected some of the errors that existed in the example on the wiki, but like I said before, I was never able to test it.

  1. I’m trying to configure this to work now, so I’ll get back when my school’s network decides to let me compile… :frowning:

So I tried statically linking the newest version of the source. I get the following errors:

1>------ Build started: Project: GAM 300 Experimental Basecode, Configuration: Debug Win32 ------
1>Compiling…
1>Common.cpp
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domcollada.h(506) : error C2039: ‘deleteCMDataArray’ : is not a member of ‘daeElement’
1> e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\dae\daeelement.h(63) : see declaration of ‘daeElement’
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domcollada.h(506) : error C3861: ‘deleteCMDataArray’: identifier not found
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domprofile_common.h(607) : error C2039: ‘deleteCMDataArray’ : is not a member of ‘daeElement’
1> e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\dae\daeelement.h(63) : see declaration of ‘daeElement’
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domprofile_common.h(607) : error C3861: ‘deleteCMDataArray’: identifier not found
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domprofile_common.h(748) : error C2039: ‘deleteCMDataArray’ : is not a member of ‘daeElement’
1> e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\dae\daeelement.h(63) : see declaration of ‘daeElement’
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\1.4\dom\domprofile_common.h(748) : error C3861: ‘deleteCMDataArray’: identifier not found
1>e:\gam 300 pitch v 0.4\source\source code\gam 300 experimental basecode\collada\dom\include\dae\daeerrorhandler.h(63) : warning C4251: ‘daeErrorHandler::_defaultInstance’ : class ‘std::auto_ptr<_Ty>’ needs to have dll-interface to be used by clients of class ‘daeErrorHandler’
1> with
1> [
1> _Ty=daeErrorHandler
1> ]
1>Build log was saved at “file://e:\GAM 300 Pitch v 0.4\Source\Source Code\GAM 300 Experimental Basecode\Debug\BuildLog.htm”
1>GAM 300 Experimental Basecode - 6 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I don’t understand why the dom is so error prone. Logically, of course, it’s more likely that the fault lies with me. So here’s what I’m doing:

I copied the source and the includes from the newest version of the dom to my project. As you can see above, the headers conflict when I try and build. Here’s the include order:

#include “…\Collada\Dom\include\dae.h”
#include “…\Collada\Dom\include\1.4\dom/domConstants.h”
#include “…\Collada\Dom\include\1.4\dom/domCOLLADA.h”
#include “…\Collada\Dom\include\1.4\dom/domProfile_COMMON.h”
#include “…\Collada\Dom\include\dae/daeSIDResolver.h”
#include “…\Collada\Dom\include\1.4\dom/domInstance_controller.h”
#include “…\Collada\Dom\include\dae/domAny.h”
#include “…\Collada\Dom\include\dae/daeErrorHandler.h”
#include “…\Collada\Dom\include\1.4\dom/domFx_surface_init_from_common.h”
#include “…\Collada\Dom\include\modules/stdErrPlugin.h”

If you’re wondering why I provide a relative path to the headers it’s because I can’t install the Collada Dom at school (and I’m expected to include all my dependencies in my project’s folder) and since I hope to dynamically link this eventually, I’m not going to change my settings to point to these temporary directories.

I’m trying to change the project settings to point to the new include directory. Just waiting for the school’s network now…

The DOM has two different build modes: static lib and DLL. If you want to use the static libs, link against libcollada_dae.lib and libcollada_dom.lib. If you want to use the DLL, link against libcolladadom13.lib. That information is for the latest DOM code on SourceForge. The last official release worked differently. It sounds like the problem could be that you’re linking against some of the static libs when you want to use the DLL. Only link against libcolladadom13.lib if you want the DLL.

Another option: zip up your test app and email it to me at x@y, and I’ll take a look at it and tell you what’s wrong.

x = steven_thomas
y = playstation.sony.com

Thanks for the response & offer but I think that I’m making some progress. I forcibly copied all the source and includes into my project and recompiled (by the advice from a friend here) and when I went to debug it, I found that there is now an internal i/o error. Here’s the report:

Warning: No IOPlugin Set! Neither DOM_INCLUDE_LIBXML or DOM_INCLUDE_TINYXML is
defined.

So I assume that I should be including the libxml headers also or something. I think that I know how to do that though. And just to make sure you realize that I’m not completely crazy, I can’t compile the libcollada_dae.lib from the newest version off svn (updated about 1 minute ago). I’m recompiling it now just to double check. If I do end up getting all the LIBs this time, then I’ll try to convert my old project to statically linking them.

Thanks again for the quick responses!

ok, so I tried using the newest libcollada_dom.lib and the old libcollada_dae.lib (since I can’t find/build the newest) and I get this:

1>E:\GAM 300\Source Code\Debug\GAM 300 Experimental Basecode.exe : fatal error LNK1120: 27 unresolved externals
1>Build log was saved at “file://e:\GAM 300\Source Code\GAM 300 Experimental Basecode\Debug\BuildLog.htm”
1>GAM 300 Experimental Basecode - 3453 error(s), 3 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

And while I may be a good debugger/syntax corrector, I’m afraid to even try to look into this one. Obviously I need the most current version of libcollada_dae.lib. How can I get this? Thanks.

Obviously I need the most current version of libcollada_dae.lib. How can I get this?
Build it.

Ok, I’m going to describe how to grab the latest code and build on Windows from scratch. Open a command prompt and navigate to the directory you want to put the DOM in.

Use svn to get the DOM

svn checkout https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/COLLADA_DOM/trunk COLLADA_DOM

also grab the external libraries

svn checkout https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/external-libs external-libs

Set an environment variable on your system COLLADA_EXTERNAL_LIBS_LOCATION to point to the external libs folder you just downloaded (e.g. c:\colladaDom\external-libs).

Now open COLLADA_DOM.sln in Visual Studio and build. Build whichever you want, static libs or the DLL, or both. Everything should build cleanly. Open up the the sample exporter .sln from samples/export. Build that. It should build and run cleanly.

That gives you a complete example of an application linking against the DOM and working. You can compare the exporter’s project settings with the settings in your app to see what’s different.

I strongly encourage you to not copy/paste the source files into your project, but instead to build the DOM and use it as a lib. If you email me your project files I can look at them and tell you what the problem is.

I strongly encourage you to not copy/paste the source files into your project, but instead to build the DOM and use it as a lib. If you email me your project files I can look at them and tell you what the problem is.

Thanks for staying with me here and responding back. I realize that copy/pasting the code into the project is a rather poor practice / solution and I have no plans to leave it in there any longer than I absolutely must. I’d send you the problematic code / project but it’s rather large (~228 MB), and I’m not sure what the school’s policy is on that (I assume that it’s very strict). I’ll try using the external libraries from the svn also and see what I get that way.

but it's rather large (~228 MB)

That’s probably with binaries right? I don’t need those. I don’t even need the source to be honest. All I need is the .vcproj/.sln. But if you don’t want to go this route, that’s fine. I’ve provided detailed instructions on how to acquire/build the DOM, and an example that shows how to use it in an app. I guess you should be able to get it working from there. Good luck, and post back with your results.

Steve

Yeah, I’ll probably be able to work this all out once I get back home. It turns out that I can’t set environment variables here at the school (like I said, they’re strict). So I’ll try it again in an hour or so, otherwise you’ll hear back from me tomorrow.

You know, it’s really stupid that we need this environment variable anyway. I’ve been meaning to fix this forever, but it’s not high on my priority list to be honest. I should fix this soon though.

Oliver and I were able to resolve this offline. It seems it was a problem in his project settings. After some tweaks he has everything working fine now.