Hi,
2016-12-30 02:33 James Cowgill:
Control: severity -1 grave
Hi,
This is RC because nothing using ogre will start anymore.
On 29/12/16 21:52, Thibaut Girka wrote:
Package: libogre-1.9.0v5
Version: 1.9.0+dfsg1-7+b2
Severity: important
Any Ogre game/application (for instance, funguloids, available in Debian)
crashes with the following output:
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
ArchiveFactory for archive type EmbeddedZip registered.
DDS codec registering
FreeImage version: 3.17.0
This program uses FreeImage, a free, open source image library supporting all
common bitmap formats. See http://freeimage.sourceforge.net for details
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abandon
This started happening since upgrading libfreeimage3, so this might be a bug in
it rather than in Ogre itself, but I haven't investigated any further yet.
This appears to be a regression in the Debian patch applied in
libfreeimage3 3.17.0+ds1-4.
Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):
for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
{
// Skip DDS codec since FreeImage does not have the option
// to keep DXT data compressed, we'll use our own codec
if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
continue;
String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));
[loop body continues]
[String is typedefed to std::string]
This code assumes that FreeImage_GetFIFExtensionList will never return
NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
the most recent Debian version of freeimage,
FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.
It is unclear to me who is wrong here. The documentation does not
suggest anything about when FreeImage_GetFIFExtensionList can fail,
although the examples always check FreeImage_FIFSupportsReading before
calling it. Can any freeimage maintainer suggest the best way to fix this?
Thanks for the analysis.
The comment on the patch seems to add some light as to the cause of this
breakage:
https://anonscm.debian.org/cgit/debian-science/packages/freeimage.git/commit/?id=a67fe8c111d0de919b7a6710d4dd5efe05fbf380
++ //allows adding a NULL node in order to not mess up plugin
++ //numbering when some are disabled. Otherwise there will be a
++ //discrepancy between FREE_IMAGE_FORMAT enumerator values and the
++ //actual format.
++ m_plugin_map[(const int)m_plugin_map.size()] = 0;
If freeimage plans to ship with this change and not revert it somehow,
the OGRE plugin for freeimage needs to check for the possibility of
having null nodes in this structure.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
