Segfault when loading imageset in SVN trunk / 0.6.9999

[IgnisInCaelum]

I'm having some crazy segfault issue (as opposed to the sane ones) using the trunk sources...
I've isolated the cause (through amazing cout-debugging skills) to this line:

CEGUI::SchemeManager::getSingleton().create((CEGUI::utf8*)"VanillaSkin.scheme");

Which is in the middle of a not-quite-pretty init()-type function in my primary application class (basically a ripoff of any given framework with an Application class or somesuch, but less clean-looking) that worked until I made the change to 0.6.9999 and swapped "loadScheme" for "create," as the Changes and Porting Tips page states that loadScheme is "renamed" to create. I haven't managed to get more than a screenshot of a backtrace (since segfaults cause all input to remain directed at my app if I let the debugger (I tend to use ddd or gdb) freeze the app), so I'll just bash out the last few lines unless someone wants that:

#10 (addr) in CEGUI::XercesHandler::startElement () at CEGUIXercesParser.cpp:327
#9 (addr) in CEGUI::Imageset_xmlHander::elementStart () at CEGUIImageset_xmlHandler.cpp:106
#8 (addr) in CEGUI::Imageset_xmlHander::elementImagesetStart () at CEGUIImageset_xmlHandler.cpp:140
#7 (addr) in Imageset () at CEGUIImageset.cpp:80
#6 (addr) in CEGUI::OgreRenderer::createTexture () at CEGUIOgreRenderer.cpp:250
#5 (addr) in OgreTexture () at CEGUIOgreTexture.cpp:179
#4 (addr) in CEGUI::OgreTexture::loadFromFile () at CEGUIOgreTexture.cpp:85
#3 (addr) in CEGUI::OgreImageCodec::load () at CEGUIOgreImageCodec.cpp:53
#2 (addr) in Ogre::image::load () from libOgreMain-1.6.2.so
#1 (addr) in Ogre::ILImageCodec::decode () from LibOgreMain-1.6.2.so
#0 (addr) in iluErrorString() from libILU.so.1

I've replaced the imagesets, looknfeels, schemes, etc., that came with Ogre (via resources.cfg) with the ones from svn, which changed nothing. Is there something else I missed? Did CrazyEddie break my ren^H^H^HSchemeManager? ( ) Thanks in advance for any help. (Also, 'sorry if I've done anything stupid...)

[CrazyEddie]

Did CrazyEddie break my ren^H^H^HSchemeManager? ( )

he might have done!

The fact that DevIL shows up in there kind of gets my attention somewhat, since I myself have had a few issues with some of the image loading libs. Can you confirm that without CEGUI the same configuration of Ogre properly loads images / textures without exploding. I'll dig a bit deeper into my own issues and post back here later.

[Edit]
Also, forgot to ask... Do the CEGUI samples run ok under ogre (you'll have to copy over an appropriate plugins.cfg file first)?

CE.

[CrazyEddie]

The segfault you're getting is a bug in Ogre; they're using the ILU library to get an error string without first having initialised the ILU lib via a call to iluInit(). This being said, the image loading still fails since for some reason DevIL is unable to load the file. Ogre configured with FreeImage works fine though.

Still trying to determine whether this is a DevIL issue, an issue with our files, or an issue with the way we're passing the file data.

CE.

[IgnisInCaelum]

Hmm... I seem to have told Ogre to use DevIL and CEGUI not to, though I'm not entirely sure how that could be an issue. I'm currently trying to un-break things, so I'll be on that for a bit.


As a side note, how does using DevIL work within an MIT licensed lib/"program"/whatever?
As another, I found (what I'm guessing is) a typo in your makefile(s):
cegui/src/ImageCodecModules/CoronaImageCodec/Makefile: -I$(top_srcdir)/cegui/include/ImageCodecModules/CoronamageCodec \
cegui/src/ImageCodecModules/CoronaImageCodec/Makefile.am: -I$(top_srcdir)/cegui/include/ImageCodecModules/CoronamageCodec \
cegui/src/ImageCodecModules/CoronaImageCodec/.svn/text-base/Makefile.am.svn-base: -I$(top_srcdir)/cegui/include/ImageCodecModules/CoronamageCodec \
cegui/src/ImageCodecModules/CoronaImageCodec/Makefile.in: -I$(top_srcdir)/cegui/include/ImageCodecModules/CoronamageCodec \

'Should be CoronaImageCodec at the end, for anyone who didn't catch that bit. (Though a magic-using library could be both awesome and terrifying...)

Argh... Is it even possible to create anything without getting stuck with *GPL'd libs? ('Dropped DevIL from Ogre, now it won't load anything)
Edit: The samples did the same thing my app did
Edit: Oops. This does belong in its own thread. I didn't realize that there was a forum for it, and utterly failed at bothering to look. I apologize for that.

[CrazyEddie]

When using Ogre with CEGUI, by default, it uses a special ImageCodec that does the image loading through the Ogre image codec.

With regards to DevIL (and other libs) and our MIT license, we always state that there may be other licensing issues to consider. While those libs that we integrate into the CEGUI core binaries are MIT compatible, those used by the external modules have various licenses - this is part of the reason for the wide selection of options

I currently can't reliably load png files from anything except freeimage - whether that be via the ogre integrated codec or from the other renderers and codecs (our own SILLY lib segs, DevIL will load the logo.png but not the DriveImages.png). This means either there's an issue with libpng or zlib (somewhat unlikely) or something wrong with the data CEGUI passes in to those libs. One way or another I'll try and get this fixed by this time tomorrow.

Thanks for the heads up WRT the Corona codec - it's the only one I don't build on my main system so this never got caught. Perhaps with a magic codec, we wouldn't have these issues

CE.

[Jamarr]

that issue really belongs in it's own thread...

[CrazyEddie]

that issue really belongs in it's own thread...

Done.

I played about with this some more last evening, and it seems that for whatever reason the png files are getting loaded as jpeg files. In our own SILLY library, I can fix this by changing the order we test image formats, obviously this is not a ideal solution because there appears to be another underlying issue. I'll do some structured testing and debugging today to (hopefully) get to the bottom of the cause of this, one way or another.

CE.

[CrazyEddie]

The non-ogre situation:
After creating a test app and eventually extracting the code that loads images in CEGUI via DevIL, I had the situation where the same code would work outside of CEGUI fine, while within CEGUI would fail. This pointed to an issue with linked items, and I eventually tracked that to some kind of conflict / clash between CEGUI and Irrlicht (which gets statically linked). Currently I am guessing that this brings about some situation where there are perhaps two copies of certain things (like png / other low-level image loading libs).

The Ogre situation:
Ogre itself (i.e. the ogre samples) work fine with DevIL, but when linked to a CEGUI app, the same situation as above arises. I can't pin this one down at the moment because it still happens when nothing else using such image libs are linked / loaded. I have some more things to look at and test. It's not a coding bug or issue in CEGUI as such, though it's certainly a 'different' kind of issue

If anyone has any good ideas / suggestions regarding this, I'm certainly happy to hear them.

CE.

[IgnisInCaelum]

Update: I just dropped in FreeImage. Everything (with CEGUI and Ogre) works now, so now I get to go deal with other problems. Yaaay.

Edit: Just yesterday: (svn commit to Ogre)
r8846 | sinbad | 2009-07-23 20:51:32 +0100 (Thu, 23 Jul 2009) | 1 line

Patch 2825998: ILImageCodec segfault fix (for those who choose to use it)

Possibly Related?

[CrazyEddie]

Cool. I'm glad you have got it to function with FreeImage.

Just yesterday: (svn commit to Ogre)
r8846 | sinbad | 2009-07-23 20:51:32 +0100 (Thu, 23 Jul 2009) | 1 line

Patch 2825998: ILImageCodec segfault fix (for those who choose to use it)

Possibly Related?

This patch was submitted by me - in response to this thread - in order to fix the segfault issue. With the patched version of Ogre, CEGUI still fails to load images when Ogre is built with DevIL, but rather than the segfault you now will get an Ogre exception thrown.

Unfortunately I do not yet have a full and proper solution to these issues, so right at the moment it's a case of not using the Ogre support for DevIL (and not using DevIL with Irrlicht, and not using DevIL in the CEGUI samples if you're linking with Irrlicht); it's a terrible situation to be in - to have to say to users, oh you can't use library 'x' with library 'y'. I'll do some more digging into this issue, and try and get a satisfactory solution.

CE.

[CrazyEddie]

Now, the other strange thing here is that this issue definitely appears to only affect the trunk code; v0-6 compiled with the same options and libs appears not to exhibit the same behaviour. So this begs the question... what exactly have I messed up?

CE.

[flomar]

Hey guys,

seems like I'm having trouble with the exact same problem you described here. Among other stuff, I'm using Ogre (svn) and CEGUI (0.7.1) on OSX (10.5). The CEGUI samples run fine, no problems there. But when integrating CEGUI into my Ogre application, I cannot load a single scheme due to problems with the images (be it png, tga, jpg or whatever).

So... what's the status quo? Any progress in that regard?

@IgnisInCaelum: You said you "dropped in freeimage". What does that mean exactly? Maybe you can give me a little piece of advice.

[CrazyEddie]

Hi,

I think the situation is still unresolved. I'll test it tomorrow to be sure.

With regards to that "dropped in freeimage" statement, I believe they mean they recompiled Ogre to use FreeImage instead of DevIL.

CE.

[CrazyEddie]

I have now tested this and confirm that the issue still exists. I have created a mantis ticket for this issue (to ensure it's not forgotten again). I will attempt to address this issue over the next couple of days.

CE.

[CrazyEddie]

This issue should now be fixed in the stable v0-7 branch of svn.

CE.