Bug#674633: libogre-dev: Uses default versions of libboost-*-dev packages

[Steve M. Robbins]

Hello,

> At the moment, I will clone the issue and assing the copy to Boost
> maintainers, to learn about their take on it.

OK, so here's my response.
Better late than never, right?  :-)



On Sun, May 27, 2012 at 12:55:11PM +0100, Manuel A. Fernandez Montecelo wrote:

> 2012/5/26 Paul D Turner <paul at cegui.org.uk>:

> > I built this code with:
> > $ g++ main.cpp -g -O -lOgreMain
> >
> > Basically, if the libboost-*dev packages are 1.48 and Ogre is built
> > against 1.49, the executable produced will hang in mutex code related
> > to the use of boost threads. If the installed libboost-*dev packages
> > match those used to build Ogre, the executable will display the message
> > and exit cleanly.
> 
> I can confirm that it's blocking for me (amd64) as well:
> 
> (gdb) bt
> #0  __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> #1  0x00007ffff73f638e in pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259
> #2  0x000000000040304a in boost::recursive_mutex::lock (this=0x60fbd0)
> at /usr/include/boost/thread/pthread/recursive_mutex.hpp:133
> #3  0x0000000000403436 in lock (this=<synthetic pointer>) at
> /usr/include/boost/thread/locks.hpp:412
> #4  unique_lock (m_=..., this=<synthetic pointer>) at
> /usr/include/boost/thread/locks.hpp:290
> #5  release (this=0x7fffffffe000) at /usr/include/OGRE/OgreSharedPtr.h:208
> #6  Ogre::SharedPtr<Ogre::DataStream>::~SharedPtr
> (this=0x7fffffffe000, __in_chrg=<optimized out>) at
> /usr/include/OGRE/OgreSharedPtr.h:155
> #7  0x0000000000402b66 in main (argc=<optimized out>, argv=<optimized
> out>) at main.cpp:15

This stack trace tells me that OgreSharedPtr uses boost::unique_lock
internally.

From this stack trace, I can see that calls at levels #2 through #6
are all functions defined in a header file.  These are all, therefore,
determined at compile time.  When building the test code using Boost 1.48,
you get the 1.48 version of unique_lock.

If there is code compiled into the Ogre library that also uses
SharedPtr, it will embed the definition of unique_lock from Boost
1.49.  If unique_lock ABI has changed between 1.48 and 1.49, you will
get undefined behaviour.  Perhaps that is what you are seeing.

My belief, therefore, is that the initial bug report is correct.  Ogre
is exposing the Boost ABI, and thus users of Ogre need to be using the
same version of Boost.

I think the remedy is to build-depend on a specific Boost -dev package
and also make libogre-dev depend on the same Boost version.  

I don't think there is a bug in boost.

Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20120923/f04d4920/attachment.pgp>