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

Sun May 27 11:55:11 UTC 2012

tags 674633 +confirmed
clone 674633 -1
reassign -1 src:boost-defaults
retitle -1 Thread locks in OGRE applications when compiled against
1.48 but linked against 1.49
block 674633 -1
stop

2012/5/26 Paul D Turner <paul at cegui.org.uk>:
> Hi Manuel,
>
> I understand that how the package is presently set up is the standard
> way to go about things, and I certainly wouldn't want to cause a bunch
> of issues by having that changed.  However, I believe the potential for
> issues is very real - mostly because I experienced them, and spent a few
> hours tracking them down. At that time, I had the 1.48 libboost-*dev
> packages as the 1.49 versions were being held back by apt-get.  I
> manually removed the 1.48 versions to allow the 1.49 packages to be
> installed, and after rebuilding the code I was working on, the issue I
> had went away.

I see.  Well, as I said I suspected that you were aware of most or all
of that, but sometimes people have with different mindsets and are not
aware or simply never thought or experienced the rationale behind
these things, so explaining it helps to understand us better :-)

> For info, I'm the lead developer on the CEGUI library, and the issue I
> had was while working on the Ogre module for CEGUI. Obviously CEGUI is
> a lot of code to suggest someone get to try and reproduce an issue, so
> I've tried to create some code for a basic test case - though I
> additionally acknowledge this may be quite hard to test because it
> basically requires downgrading the libboost-*dev packages to 1.48.

For reference, there's snapshot.debian.org containing all old versions
of packages ever:
http://snapshot.debian.org/package/boost1.48/
http://snapshot.debian.org/package/boost-defaults/

I needed to install these packages:
libboost1.48-dev_1.48.0-3_amd64.deb
libboost-date-time1.48.0_1.48.0-3_amd64.deb
libboost-date-time1.48-dev_1.48.0-3_amd64.deb
libboost-date-time-dev_1.48.0.3_amd64.deb
libboost-dev_1.48.0.3_amd64.deb
libboost-serialization1.48.0_1.48.0-3_amd64.deb
libboost-serialization1.48-dev_1.48.0-3_amd64.deb
libboost-thread1.48.0_1.48.0-3_amd64.deb
libboost-thread1.48-dev_1.48.0-3_amd64.deb
libboost-thread-dev_1.48.0.3_amd64.deb

> 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

It happens when compiling as instructed, with the command above and
when libboost-thread-dev is depending on 1.48 versions (and the
corresponding symbolic link does the same), but the binary gets linked
to 1.49 anyway:

$ ldd a.out  | grep boost
        libboost_thread.so.1.49.0 =>
/usr/lib/libboost_thread.so.1.49.0 (0x00007f4aea77b000)

$ stat /usr/lib/libboost_thread* | grep File
  File: `/usr/lib/libboost_thread.a'
  File: `/usr/lib/libboost_thread-mt.a' -> `libboost_thread.a'
  File: `/usr/lib/libboost_thread-mt.so' -> `libboost_thread.so.1.48.0'
  File: `/usr/lib/libboost_thread.so' -> `libboost_thread.so.1.48.0'
  File: `/usr/lib/libboost_thread.so.1.48.0'
  File: `/usr/lib/libboost_thread.so.1.49.0'

> Another scenario I thought of (but did not experience directly) is if
> a developer has code that uses boost-threads directly as well as
> using Ogre. Here it would be natural for the developer to link their
> code to libboost_thread and libOgreMain.  If the libboost-thread-dev
> is, say, version 1.48, and libOgreMain - as you correctly pointed out -
> has references to the 1.49 version of libboost_thread, the executable
> would bring in two versions of the same lib (a linker warning is
> produced announcing the possible conflict).  A developer could skip
> directly linking libboost_thread and implicitly pick up the version
> referenced by libOgreMain, but then they have the situation of having
> compiled against the 1.48 headers but have the 1.49 library (which may
> or may not be harmless, depending on whether ABI compatibility between
> the two library versions was maintained - a rarity when dealing with
> boost, I think).

Indeed, when using:

  $ g++ main.cpp -g -O -lOgreMain

it doesn't generate any error/warning, but when using this directly it
at least gives you a warning:

  $ g++ main.cpp -g -O -lOgreMain -lboost_thread
  /usr/bin/ld: warning: libboost_thread.so.1.49.0, needed by
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libOgreMain.so,
may conflict with libboost_thread.so.1.48.0

Additionally, I discovered that OGRE's pkg-config isn't telling the
application that other libraries are needed (only pthread), which I
think that it's wrong:

$ pkg-config --cflags OGRE
-pthread -I/usr/include/OGRE
$ pkg-config --libs OGRE
-lOgreMain -lpthread

I don't know if there's a way that fix this problem with linker flags
emmitted by pkg-config, though.  If it were possible to also emit
information on the versions needed perhaps it would, but I don't know
if it's possible, and in any case I haven't seen anything like that
before.

> I should probably add that, in my opinion, the potential for issues to
> occur is highly unlikely to be limited to Ogre. I'm really not certain
> what the best thing, or the right thing to do in this situation is.
> All I can say is that the issues that can occur are indeed very real,
> though probably would only ever affect a minority of users and only
> when specific circumstances exist.
>
> Regardless of what, if any, action is taken, I hope this helps to
> explain the situation a little better.  It may also help someone in the
> future if they're unfortunate enough to experience similar things, and
> at the very least it gives me somewhere to point to if CEGUI users
> report this as a bug in CEGUI ;)

Yes, it's a useful and very detailed bug report, thank you very much.

I also agree that the issue could affect other people, so if the
problem is really caused by conflicting versions of libboost-thread,
the conflicts should be in this package.  But I guess that this
solution has very serious implications for the whole archive, I don't
know.

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

Cheers.