Ogre 1.9 update : Segmentation fault

[Supermanu]

Hi all,

Since the last 1.9 update, I'm unable to launch an application with Ogre (works perfectly with 1.8 ) even the SampleBrowser crash. I've also tried this repo : http://github.com/scrawl/ogre-sdl2-test but with the same result. I'm a linux user (archlinux).

When I tried to run them with gdb, the faulty guy always seems to be Ogre::MaterialManager::MaterialManager() when we initialize a root object.
Is there something I can do or do you need more info ?

It's not big deal since I can easily downgrade, but any help might be nice.

Thanks !

[masterfalcon]

We haven't run into this issue ourselves. Would you be able to provide a stack trace and any more information that might help us debug the issue?

[Imajie]

I'm also running archlinux and I hit the same issue. It only seems to actually happen when Ogre is built in Release mode. If I build Ogre in either Debug or RelWithDebInfo, the tutorial framework runs fine, however when built with Release it segfaults with the same error Supermanu had when Ogre::MaterialManager::MaterialManager() is called from Ogre::Root.

[lingfors]

Is this from the tag 1-9-0? Or is it from some other revision of the source, and if so which revision? (Just saying "the last update" is about as vague as it gets, as it's very ambiguous, and also varies depending on at which time it is read...)

[Supermanu]

It's from the tag 1-9-0.
And as Imajie, it also runs for me with the debug mode.

[scrawl]

Holy crap. I'm also getting this bug. Ubuntu 12.04 64 bit, GCC 4.8.
I'm amazed this wasn't noticed before. I guess no one's using the Release configuration for developing (I just always use RelWithDebInfo, which worked fine).
Might be a good idea to try out the Release configuration, before creating a release?
Since it only occurs in Release, I can't really get a meaningful backtrace. Perhaps try running Debug in valgrind and see if it complains about anything? Don't have time to do that right now.

Code: Select all

0x00007ffff787e661 in Ogre::MaterialManager::MaterialManager() () from /usr/lib/libOgreMain.so.1.10.0
(gdb) bt
#0  0x00007ffff787e661 in Ogre::MaterialManager::MaterialManager() () from /usr/lib/libOgreMain.so.1.10.0
#1  0x00007ffff788fab5 in Ogre::Root::Root(std::string const&, std::string const&, std::string const&) () from /usr/lib/libOgreMain.so.1.10.0
#2  0x0000000001173bff in OgreInit::OgreInit::init (this=0x1789380, logPath=...) at /home/scrawl/Dev/openmw/components/ogreinit/ogreinit.cpp:44
#3  0x0000000000b610b8 in OEngine::Render::OgreRenderer::configure (this=0x1789350, logPath=..., renderSystem=..., rttMode=...) at /home/scrawl/Dev/openmw/libs/openengine/ogre/renderer.cpp:53
#4  0x0000000000f6a5b9 in OMW::Engine::prepareEngine (this=0x7fffffffe2e0, settings=...) at /home/scrawl/Dev/openmw/apps/openmw/engine.cpp:341
#5  0x0000000000f6bcb4 in OMW::Engine::go (this=0x7fffffffe2e0) at /home/scrawl/Dev/openmw/apps/openmw/engine.cpp:479
#6  0x0000000000f5cdc1 in main (argc=1, argv=0x7fffffffe688) at /home/scrawl/Dev/openmw/apps/openmw/main.cpp:278

[scrawl]

Valgrind didn't have anything to say... but with some good old cout debugging, I found out that it chokes on this line in MaterialManager::MaterialManager():

Code: Select all

		OGRE_THREAD_POINTER_SET(mSerializer, OGRE_NEW MaterialSerializer());

[masterfalcon]

Out of curiosity, what threading library are you using?

Also, you might not be on the 1.9 branch. See this: "/usr/lib/libOgreMain.so.1.10.0"

[lingfors]

I'm on 1.9, always running Release unless I run into a bug I can't nail down without debug info, and I'm not getting this... I'm on Windows, though...

[scrawl]

Yes, I'm on 1.10 right now. But it shouldn't be making a big difference atm, and since it's apparently the same bug the OP had in 1.9 ..

Threading is default (boost)

I'm running a bisect now. 5 test left.

[scrawl]

Here we go:

The first bad revision is:
changeset: 4711:2f646d7c9d83
branch: v1-9
user: David Rogers <masterfalcon@ogre3d.org>
date: Mon Jun 10 09:43:49 2013 -0500
summary: [iOS] Build fixes when enabling libc++ support.

[scrawl]

Yeah I found the issue: https://bitbucket.org/sinbad/ogre/pull- ... in-19/diff
How do you want to handle this? Re-tag 1.9.0 or create a 1.9.1 tag? I'd say that we don't need to keep a broken tag.

[Imajie]

Thanks, I can confirm that the patch fixes the release build issues on archlinux. It's a strange bug when building with debug info makes it go away.