Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

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

  1. #11
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  2. #12
    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:

    Code :
    _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)

  3. #13
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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

  4. #14
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  5. #15
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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

  6. #16
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I added a note to the wiki.

  7. #17
    Junior Member
    Join Date
    May 2008
    Posts
    6
    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...

  8. #18
    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:

    Code :
    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.

  9. #19
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  10. #20
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •