Ogre 1.4 under SuSE 10.2 Segfault [Solved with a workaround]

[merlinblack]

Hi, I'm getting a segfault on my own programs and also all of the samples.

Everything compiles fine. It seems to be something do with the BlueHightWay font, or creating images for it.

SuSE 10.2
Ogre 1.4 from CVS
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)

Here is some debug output, hopefully pinpointing the offender...

This is the Water sample program, which starts normally, shows the config dialog, and continues untill the point shown. (I've cut before the error to give some context.)

Info: Freetype returned null for character 158 in font BlueHighway
Info: Freetype returned null for character 159 in font BlueHighway
Info: Freetype returned null for character 160 in font BlueHighway
Texture: BlueHighwayTexture: Loading 1 faces(PF_BYTE_LA,512x512x1) with hardware generated mipmaps from Image. Internal format is PF_BYTE_LA,512x512x1.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230128928 (LWP 19567)]
0xb6e8b730 in FreeImage_SetTagValue () from /usr/lib/libfreeimage.so.3
(gdb) where
#0 0xb6e8b730 in FreeImage_SetTagValue () from /usr/lib/libfreeimage.so.3
#1 0xb6e66c28 in InitPNG () from /usr/lib/libfreeimage.so.3
#2 0xb6e53f11 in FreeImage_LoadFromHandle () from /usr/lib/libfreeimage.so.3
#3 0xb6e52d2b in FreeImage_LoadFromMemory () from /usr/lib/libfreeimage.so.3
#4 0xb7e572a6 in Ogre::FreeImageCodec::decode (this=0x80714f0,
input=@0xbfb93790) at OgreFreeImageCodec.cpp:333
#5 0xb7c55692 in Ogre::Image::load (this=0xbfb93738, stream=@0xbfb93790,
type=@0xbfb937b8) at OgreImage.cpp:409
#6 0xb6a165e5 in Ogre::GLTexture::loadImpl (this=0x88b4cd8)
at OgreGLTexture.cpp:272
#7 0xb7d7a647 in Ogre::Resource::load (this=0x88b4cd8, background=false)
at OgreResource.cpp:116
#8 0xb7e14c7e in Ogre::TextureManager::load (this=0x889a048, name=@0x88bdd38,
group=@0x88bd760, texType=Ogre::TEX_TYPE_2D, numMipmaps=2147483647,
gamma=1, isAlpha=false, desiredFormat=Ogre::PF_UNKNOWN)
at OgreTextureManager.cpp:78
#9 0xb7e17b99 in Ogre::TextureUnitState::ensureLoaded (this=0x88bdb00,
frame=0) at OgreTextureUnitState.cpp:987
#10 0xb7e1854f in Ogre::TextureUnitState::_load (this=0x88bdb00)
at OgreTextureUnitState.cpp:918
#11 0xb7d47f84 in Ogre::Pass::_load (this=0x88bd9d0) at OgrePass.cpp:973
#12 0xb7e0a99d in Ogre::Technique::_load (this=0x88bd188)
at OgreTechnique.cpp:420
---Type <return> to continue, or q <return> to quit---
#13 0xb7c7b764 in Ogre::Material::loadImpl (this=0x88bd750)
at OgreMaterial.cpp:132
#14 0xb7d7a647 in Ogre::Resource::load (this=0x88bd750, background=false)
at OgreResource.cpp:116
#15 0xb7d1066b in Ogre::OverlayElement::setMaterialName (this=0x890ea60,
matName=@0x890cc34) at OgreOverlayElement.cpp:331
#16 0xb7d24f24 in Ogre::PanelOverlayElement::setMaterialName (this=0x890ea60,
matName=@0x890cc34) at OgrePanelOverlayElement.cpp:178
#17 0xb7d13392 in Ogre::OverlayElementCommands::CmdMaterial::doSet (
this=0xb7f22aa4, target=0x890ea60, val=@0x890cc34)
at OgreOverlayElementCommands.cpp:88
#18 0xb7e03b8d in Ogre::StringInterface::setParameter (this=0x890ea60,
name=@0x890cc30, value=@0x890cc34) at OgreStringInterface.cpp:60
#19 0xb7d192b7 in Ogre::OverlayManager::parseElementAttrib (this=0x8070688,
line=@0xbfb93c28, pOverlay=0x88b4420, pElement=0x890ea60)
at OgreOverlayManager.cpp:438
#20 0xb7d1a01d in Ogre::OverlayManager::parseNewElement (this=0x8070688,
stream=@0xbfb93e9c, elemType=@0x89333d4, elemName=@0x89333d8,
isContainer=true, pOverlay=0x88b4420, isTemplate=false,
templateName=@0xbfb93d14, container=0x0) at OgreOverlayManager.cpp:337
#21 0xb7d1a7ec in Ogre::OverlayManager::parseChildren (this=0x8070688,
stream=@0xbfb93e9c, line=@0xbfb93dd8, pOverlay=0x88b4420,
isTemplate=<value optimized out>, parent=0x0) at OgreOverlayManager.cpp:404
---Type <return> to continue, or q <return> to quit---
#22 0xb7d1ba43 in Ogre::OverlayManager::parseScript (this=0x8070688,
stream=@0xbfb93e9c, groupName=@0x8098968) at OgreOverlayManager.cpp:242
#23 0xb7d82a86 in Ogre::ResourceGroupManager::parseResourceGroupScripts (
this=0x80679d0, grp=0x8098968) at OgreResourceGroupManager.cpp:785
#24 0xb7d838da in Ogre::ResourceGroupManager::initialiseAllResourceGroups (
this=0x80679d0) at OgreResourceGroupManager.cpp:144
#25 0x0804fc69 in ExampleApplication::setup (this=0xbfb93f74)
at ../../../Samples/Common/include/ExampleApplication.h:135
#26 0x0804cc41 in main ()
at ../../../Samples/Common/include/ExampleApplication.h:89
(gdb) quit
The program is running. Exit anyway? (y or n) y
merlin@SupraNox:/ext/Programming/ogrenew/Samples/Common/bin>

Thanks in advance for any help.

[merlinblack]

Some more info...

After a restart, problem disappears, for a short time. After running any of the samples repeatedly, eventually the problem arises. Always with mipmaps it seems.

Gfx card: nVidia 6800 AGP
Driver version: 1.0.9631-0.1 i586

Could video memory be left unfree'd after each run of a sample app?

Thanks.

[Azatoth]

There are problems with FreeImage being used together with libpng. Search the forum for "FreeImage_SetTagValue".

[merlinblack]

Thanks Azatoth,

So the up shot is, use the Xt config box, to avoid linking the system libpng untill version 1.4.1 is released, and then use DeVIL.

I guess I can live with that.

I wounder if FreeImage could be fixed by inluding all its staticly linked libarys inside a namespace? Would this effectively give each exported symbol a prefix

I'm surprised this does not appear more often, every linux system I ever used has libpng installed .

Thanks!

[Azatoth]

Yep, that's the plan.

Note that the libraries used by freeimage are C libraries which doesn't have namespaces. They would need to rename each and every symbol instead.

It does not appear often because no linux distro that I know of supply freeimage in their repositories (presumably since it's incompatible with the base image libs in the system).

Thanks Azatoth,

So the up shot is, use the Xt config box, to avoid linking the system libpng untill version 1.4.1 is released, and then use DeVIL.

I guess I can live with that.

I wounder if FreeImage could be fixed by inluding all its staticly linked libarys inside a namespace? Would this effectively give each exported symbol a prefix

I'm surprised this does not appear more often, every linux system I ever used has libpng installed .

Thanks!

[sinbad]

Azatoth's patch is in CVS branch v1-4 now if you want to try it; you just have to configure FreeImage off and it should use DevIL I believe.

[Matte+]

This bug is really critical for linux users, there's some way to get the
patches in a separate way? Or can you tell us which files need to be patched
and what revision to get to create the patch?

Most linux users are stuck to 1.2 until next release, actually....

P.S.: 1.4.1 is compiling on 32 bit archs but not on 64 bit ones, with a link error:

Code: Select all

.libs/OgreGLRenderSystem.o: In function `Ogre::GLRenderSystem::shutdown()':
OgreGLRenderSystem.cpp:(.text+0x217b): undefined reference to
`Ogre::HighLevelGp
uProgramManager::removeFactory(Ogre::HighLevelGpuProgramFactory*)'
collect2: ld returned 1 exit status
libtool: install: error: relink `RenderSystem_GL.la' with the above command
before installing it

[Azatoth]

Ogre 1.4.1 already contains the patches.

I've compiled 1.4.1 on x86_64 without problems. Perhaps you need to clean up an older release first?

This bug is really critical for linux users, there's some way to get the
patches in a separate way? Or can you tell us which files need to be patched
and what revision to get to create the patch?

Most linux users are stuck to 1.2 until next release, actually....

P.S.: 1.4.1 is compiling on 32 bit archs but not on 64 bit ones, with a link error:

Code: Select all

.libs/OgreGLRenderSystem.o: In function `Ogre::GLRenderSystem::shutdown()':
OgreGLRenderSystem.cpp:(.text+0x217b): undefined reference to
`Ogre::HighLevelGp
uProgramManager::removeFactory(Ogre::HighLevelGpuProgramFactory*)'
collect2: ld returned 1 exit status
libtool: install: error: relink `RenderSystem_GL.la' with the above command
before installing it

[sinbad]

I've also build & run the latest release on x86 openSUSE and it's fine.