Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues

[Manuel A. Fernandez Montecelo]

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.montezelo at gmail.com>