Bus error occured (Mac OSX + COLLADA DOM2.0)

Hi,
I’m getting an error on running my app.
Only at debug build, Release build is OK.

(I use Mac OSX Leopard, Xcode 3.0, COLLADA DOM 2.0, 2.1.)

At

DAE dae; 
colladaRoot = dae.open(fileName); 

Error message is :

The Debugger has exited due to signal 10 (SIGBUS).The Debugger has exited due to signal 10 (SIGBUS).

When I debugging, “EXC_BAD_ACCESS” is occurred.
and program stopped at this line :

#0	0x000023fb in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::_S_right at stl_tree.h:497 
#1	0x00002bad in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::_M_erase at stl_tree.h:1056 
#2	0x00869415 in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::clear at stl_tree.h:666 
#3	0x0086947b in std::map<daeSidRef, daeSidRef::resolveData, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::clear at stl_map.h:465 
#4	0x00867ebb in daeSidRefCache::clear at daeSIDResolver.cpp:497 
#5	0x00874854 in daeSTLDatabase::insertElement at daeSTLDatabase.cpp:222 
#6	0x00871db4 in daeSTLDatabase::insertChildren at daeSTLDatabase.cpp:232 
#7	0x008743dd in daeSTLDatabase::insertElement at daeSTLDatabase.cpp:195 
#8	0x00871db4 in daeSTLDatabase::insertChildren at daeSTLDatabase.cpp:232 
#9	0x008743dd in daeSTLDatabase::insertElement at daeSTLDatabase.cpp:195 
#10	0x0085629c in daeDocument::insertElement at daeDocument.cpp:25 
#11	0x008587ff in daeElement::setDocument at daeElement.cpp:144 
#12	0x0084bd78 in daeElement::setDocument at daeElement.h:332 
#13	0x0084bef9 in daeDocument::setDomRoot at daeDocument.h:54 
#14	0x00872a59 in daeSTLDatabase::createDocument at daeSTLDatabase.cpp:87 
#15	0x00871a8f in daeSTLDatabase::insertDocument at daeSTLDatabase.cpp:72 
#16	0x0085ddbc in daeIOPluginCommon::read at daeIOPluginCommon.cpp:82 
#17	0x0084a283 in DAE::openCommon at dae.cpp:174 
#18	0x0084a370 in DAE::open at dae.cpp:180 

Does anybody know what’s wrong ?

thanks!

That’s a weird error. Looks like memory corruption. On Linux I use valgrind to check for memory errors. I’m not sure what you’d use on Mac.

Does domTest run properly? “domTest -all” to run all the tests.

Steve

Thank you very much!

domTest runs properly.
>All tests passed.
Both Release build and Debug build.

There are some tools for checking memory error in Mac OSX. (“MallocDebug” and “Instruments”)
But I couldn’t find out any problems.
(Usually, Debug build application terminated, and there were no information… In fact, I don’t know well about these tools.)

Are there any errors in Xcode or my environment…?
I have no idea…
I’m busy today, but I will try reinstalling Xcode…

I’m busy today, but I will try reinstalling Xcode…
Woah, you really shouldn’t have to do that. I’m not sure what the error is though. Did you follow the setting up guide to get your Xcode project set up? There isn’t really anything special you need to do for the Mac build so I kind of doubt you screwed something up there.

It might help to build a test program manually on the command line, just to make sure there isn’t an Xcode problem somewhere. Rebuild domTest with ‘verbose=yes’ to see how a DOM client app is built on the command line.

Just based on your debugger dump, it appears that the DOM has already started reading the document when it dies. It’s possible that your file has something strange in it that is triggering the crash. I would suggest trying to backtrack from the point of failure to see what it was reading at the time the crash occurred.

You might also want to check your file with the Collada Coherency Checker or post the file here so we can have a look at it.

Sadly, valgrind isn’t available for the Mac yet…someone at apple has done a usable port but is having trouble getting Apple to approve releasing the code :frowning:

tsurushuu, it is indeed a weird error, I have successfully compiled that under Mac OS X 10.5.2 with no errors, I wrote a tutorial specifically for Leopard, you can find it here: http://www.black-fluid.com/?p=4

It might helps, there is more to come, read through it, there might be something you spot which could help.

I read “setting up guide” tutorial, and Toxinide’s tutorial,
(Thank you very much! Toxinide, )
I did exactly same way as these.

I tried building my app from terminal.
This worked properly! no error.
g++ -c main.cpp -Wall -g -D_DEBUG -arch i386 -Iinclude -Iinclude/1.4 -o test.o
g++ -Wall -g -D_DEBUG -arch i386 -o testtest test.o -Fbuild/mac-1.4 -framework Collada14Dom

But, Xcode still generates buggy app when Debug build…

I uses Japanese version of Mac OSX Leopard.
And I use Macports, installed many applications. (TeX, programming tool…)
Is this suspicious?

This is my code:

#include <iostream>
using namespace std;

#include <dae.h>
#include <dom/domCOLLADA.h>

domCOLLADA* colladaRoot = 0;

int main(int argc, char* argv[]) {
	
	string fileName = "valid.dae";
	if(argc > 1){
		fileName = argv[1];
	}
	
	DAE dae;
	colladaRoot = dae.open(fileName);
	
	cout << "OK" << endl;
	
	return 0;
}

.dae file:

<?xml version="1.0" encoding="UTF-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
	<asset>
		<contributor/>
		<created>2008-04-08T13:07:52-08:00</created>
		<modified>2008-04-08T13:07:52-08:00</modified>
	</asset>
</COLLADA>

I uses Japanese version of Mac OSX Leopard.
And I use Macports, installed many applications. (TeX, programming tool…)
Is this suspicious?
To my knowledge that shouldn’t be a problem.

I’m stumped about what the issue could be. Here are a couple more things to try.

  • Comment out the dae.open line. Does the app run fine then?
  • Use otool -L on both the working exe produced via the command line and the broken exe produced via Xcode. Do they link against the same libs?

otool -L ~/…/testapp

Hi tsurushuu
I am glad you like the tutorial, your code seems fine, if you can compile from the Terminal then you have something not setup correctly with XCode. Have you added the Header path, the official guide states:

In Xcode add the DOM framework to your project (Project->Add to Project). In the build configuration of your target, add <dom-path>/Collada14Dom.framework/Headers to Header Search Paths. For a debug build the framework name is Collada14Dom-d.framework, so adjust paths accordingly.

It might as simple as that.

Sorry, in my previous comment,
I linked Release version of COLLADA DOM…
I compiled again, this time, link Debug version.

g++ -Wall -g -D_DEBUG -arch i386 -o testtest test.o -Fbuild/mac-1.4-framework-d -framework Collada14Dom-d

Then, this was broken…
Bus error was occurred.

I tried simplest code.
This still has an error…

#include <dae.h>
#include <dom/domCOLLADA.h>

domCOLLADA* colladaRoot = 0;

int main(int argc, char* argv)
{

DAE dae;
// colladaRoot = dae.open(fileName);

return 0;
}

This time, debugger stopped on this line,
in destructor of DAE.
More precisely, in daeSidRefCache::clear

This is same to error message of my first post.

Any bug? or My std library is broken?

#0 0x00001df9 in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::_S_right at stl_tree.h:497
#1 0x000025ab in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::_M_erase at stl_tree.h:1056
#2 0x00868415 in std::_Rb_tree<daeSidRef, std::pair<daeSidRef const, daeSidRef::resolveData>, std::_Select1st<std::pair<daeSidRef const, daeSidRef::resolveData> >, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::clear at stl_tree.h:666
#3 0x0086847b in std::map<daeSidRef, daeSidRef::resolveData, std::less<daeSidRef>, std::allocator<std::pair<daeSidRef const, daeSidRef::resolveData> > >::clear at stl_map.h:465
#4 0x00866ebb in daeSidRefCache::clear at daeSIDResolver.cpp:497
#5 0x00871120 in daeSTLDatabase::clear at daeSTLDatabase.cpp:373
#6 0x0087114f in daeSTLDatabase::~daeSTLDatabase at daeSTLDatabase.cpp:24
#7 0x0084aafd in DAE::~DAE at dae.cpp:76
#8 0x0084ad33 in DAE::~DAE at dae.cpp:81
#9 0x000018ab in main at main.cpp:13

And I will try otool -L

Damn, I don’t really have any good answers unfortunately. The only thing I had to go on was that it was working outside of Xcode, but without that I’m pretty much out of ideas. “It works fine on my Mac”, but I realize how useless that statement is.

One thing you could try is downloading DOM 2.0 (also available on Sourceforge) which didn’t have daeSidRefCache. I really doubt daeSidRefCache is actually the problem though.

Without being able to sit down at your machine to try stuff I’m not sure what else to do. I’ll keep thinking about it though.

I was able to reproduce your crash… In Xcode I used the “New project assistant” and created a “command line utility -> C++ Tool” project. Then I configured the project to link against the DOM as mentioned in the Wiki and used the above code snippet of creating a DAE instance.

I found the following reason for your application crash:

In DEBUG mode of your Xcode project you have those additional preprocessor macros in “Preprocessor Macros” of your build settings:

_GLIBCXX_DEBUG_PEDANTIC=1
_GLIBCXX_DEBUG=1

If you remove them, rebuild, your app won’t crash, at least that worked for me. Those macros seem to let the libcxx behave different in some way. It might be interesting why it does with the DOM in daeSidRef. Steve, maybe you can reproduce the crash, too, using the additional preprocessor macros? But maybe that issue is not too important and it could also be a libcxx bug. At least we can document it now.

  • h

…sorry for multiple edits of my posting (hope you see the most recent one, steve posted all necessary info in the following posts)

Great catch Heinrich! I made an app in Xcode that links against the debug DOM and I got the crash. I found the preprocessor defines and removed them, and then the app ran fine.

I found a thread where someone was complaining about this same problem with a mysql app: http://www.nabble.com/Release-works,-Debug-(still-crashes-on-OS-X-Leopard,-Xcode-3.0-(Part-2)-td14143971.html

The url formatting is screwed up… make sure to copy/paste the entire url above into your browser.

This isn’t a problem with the DOM code. The _GLIBCXX_DEBUG preprocessor flag tells gcc to use an STL that has additional runtime debugging checks, but it’s an all-or-nothing flag: either all code in your app (including libs like the DOM) have to have that flag or you shouldn’t have that flag anywhere. Since the DOM doesn’t build with that flag, you get problems in the debug build of your app. All that info is taken from the linked thread… hopefully they’re not mistaken about any of this.

I really feel this is a bad decision on Apple’s part. From their perspective I guess they’re expecting you to build all code in your app with Xcode, so the settings will be consistent. But that’s not realistic; OS X has a ton of Unixy libs available that, like the DOM, aren’t built with Xcode and therefore don’t define this flag by default. This flag should be something you have to turn on instead of something that’s on by default.

Anyway, there are at least two ways to address this problem. One is to remove those flags from your preprocessor settings, and the other is to customize the DOM to build with those flags. That shouldn’t be too difficult. Make a folder ~/.collada-dom and add a file customSettings.mk with these contents:

ifeq ($(conf),debug)
ccFlags += -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
endif

That should build the DOM with the appropriate flags. I’m in the process of testing this now. I’ll update the wiki shortly.

Special shout out to Heinrich for spotting the problem. Great work buddy.

Steve

Actually, one thing that still isn’t explained is how the app that tsurushuu built on the command line was still failing. It doesn’t look like he included these flags in his command line build.

I added the glibcxx preprocessor flags and rebuilt the DOM, but I still get crashes unfortunately. I think the problem is the external libs, which are precompiled. Specifically you’d need to rebuild PCRE to include this flag, and also Boost filesystem if you want to run domTest. Argh, what a pain in the ass.

I think the best thing is going to be to just take the flag out of your Xcode project.

Steve

I added a note to the wiki.

In my project, “Preprocessor Macros” in build setting is empty…

I doubted my Xcode’s environment, so I created new account of OSX,
Then I tried in it.
But, same result…

When I built my app from terminal, this app caused an error.
But, Debug mode of “domTest” is OK…

That’s odd. Have you checked both, the “project settings” and the settings of your target in Xcode? They would also show up only in your Debug-configuration, not in Release.

If you build your testing case via command line, and you still get a crash, then the glibcxx debug defines have to come from somewhere else, either from your testing case, or in some binary linked with the DOM.

You can check the following:

When compiling your main.cpp, try using the “-E -dM” flags and leave out the “-o test.o” to let the compiler output a list of preprocessor definitions for this compile step.

So, in your case, it might look similar to this:

g++ -Wall -c -E -dM main.cpp -g -D_DEBUG -arch i386 -Iinclude -Iinclude/1.4

Search for the _GLIBCXX_DEBUG_PEDANTIC and _GLIBCXX_DEBUG definition in the output.

If you haven’t found any, maybe your build of the DOM was build with them already, in this case you can try adding the defs to your testing case build, this way your app shouldn’t crash.

Steven: I tried rebuilding the DOM with the glibcxx debug defs, and was able to run a binary that was compiled with them, too. So for me the crash was gone… are you sure this won’t work for you? I modified DOM_PATH/make/common.mk to add the defs in line13, just for testing, which is probably not the best place for custom defs, but it worked.

Steven: I tried rebuilding the DOM with the glibcxx debug defs, and was able to run a binary that was compiled with them, too. So for me the crash was gone… are you sure this won’t work for you? I modified DOM_PATH/make/common.mk to add the defs in line13, just for testing, which is probably not the best place for custom defs, but it worked.
Yeah, this was just a mistake on my part. The customSettings.mk file can’t be used to set config-specific values in the way I’m trying to do. Those values get overwritten later, so my build didn’t have the flags. I’m rebuilding now, this time with the flags. I should add a configSettings.mk file for config-specific customizations.

Modifying the DOM makefile line as Heinrich suggests also fixes the problem for me. I’ll add that tip to the wiki. Thanks Heinrich!

tsurushuu, are you sure that you don’t have these flags in your Xcode project? I get the crash in the same exact place you reported so it’d be strange if this were a totally separate problem. As Heinrich mentioned, you won’t see the flags in your project settings. You need to open up the settings for the build target. An easy way to see if these settings are in your files would be to do a search on the command line: find test/app/path | xargs grep -i glibcxx

I still can’t explain why the debug app that you built on the command line crashes in the same way.