Boost logo

Boost Users :

From: Richard Newman (richard_at_[hidden])
Date: 2005-08-11 15:12:50

I took the .cpp file where I wrote the TrivialTest and used gcc (3.3.3)
to produce the expanded listing (using -E). I then substituted that
expanded version back as the .cpp file and rebuilt via automake (using
-g3 -O0) for debug. Now my backtrace is more informative:

(gdb) cont
Running 1 test case...

*** No errors detected

Program received signal SIGINT, Interrupt.
0x008a4402 in ?? ()
(gdb) backtrace
#0 0x008a4402 in ?? ()
#1 0x0064dcbe in __lll_mutex_lock_wait () from /lib/tls/
#2 0x0064ac84 in _L_mutex_lock_29 () from /lib/tls/
#3 0x003fd840 in _dl_runtime_resolve () from /lib/
#4 0x0036e8ea in scoped_lock (this=0x8aab67c, m=@0x3fd840) at
#5 0x0036e8ea in scoped_lock (this=0xfeedd910, m=@0x8aab67c) at
#6 0x0036e7dc in boost::detail::sp_counted_base::release
(this=0x8aab670) at shared_count.hpp:140
#7 0x0036e170 in ~shared_count (this=0x8aab650) at shared_count.hpp:378
#8 0x00377392 in ~shared_ptr (this=0x8aab64c) at unit_test_suite.hpp:60
#9 0x003772eb in ~test_case (this=0x8aab630) at unit_test_suite.hpp:60
#10 0x0037719c in ~function_test_case (this=0x8aab630) at
#11 0x00b45d45 in boost::unit_test::ut_detail::normalize_test_case_name
() from /usr/lib/
#12 0x00b46018 in
boost::unit_test::test_case*&, boost::unit_test::test_case**>, void
(*)(boost::unit_test::test_case*)> () from
#13 0x00b459cb in boost::unit_test::test_suite::~test_suite () from
#14 0x00b46ddc in main () from /usr/lib/
#15 0x00423ad4 in __libc_start_main () from /lib/tls/
#16 0x08048a3d in _start ()

Looks like the Boost unit test framework is possibly not able to release
a reference to the unit test and thus holding the mutex hostage.

Are there recent bug fixes in this area or known issues with regard to FC2?


Richard Newman wrote:
> When I reduced the test set to the following test, it still hangs but
> says that one test passed (as the 48 I used before did).
> {
> int x = 0;
> x = 1;
> }
> When I remove this one test and so have no tests, no hang occurs. It
> simply says no errors and terminates normally. I guess I can review the
> macro represented by BOOST_AUTO_UNIT_TEST to see what might be invoked
> here.
> The make session for both cases was the same (excepting of course the
> test output):
> --------------------
> $ make
> if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
> -I. -I/home/<somepath>/project/src/mylibrary -I../..
> -I/home/<somepath>/project/src -I/home/<somepath>/construct/dep/include
> -D__CSGA_REVISION__='"2057M"' -pthread -Werror -Wall -g -O2 -MT
> function.lo -MD -MP -MF ".deps/function.Tpo" -c -o function.lo
> function.cpp; \
> then mv -f ".deps/function.Tpo" ".deps/function.Plo"; else rm -f
> ".deps/function.Tpo"; exit 1; fi
> g++ -DHAVE_CONFIG_H -I. -I/home/<somepath>/project/src/mylibrary
> -I../.. -I/<somepath>/project/src -I/<somepath>/dep/include
> -D__CSGA_REVISION__=\"2057M\" -pthread -Werror -Wall -g -O2 -MT
> function.lo -MD -MP -MF .deps/function.Tpo -c function.cpp -fPIC -DPIC
> -o .libs/function.o
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -pthread -Werror -Wall
> -g -O2 -o -rpath /<somepath>/release/product/lib
> <several .lo files listed> -L/<somepath>/dep/lib -lxslt -lxml2 -lxmlwrapp
> rm -fr .libs/mylibrary.0 .libs/mylibrary.0.0.0 .libs/
> .libs/mylibrary.lai
> g++ -shared -nostdlib
> /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o
> /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbeginS.o
> <several .o files listed under .libs/> -L/usr/lib -L/<somepath>/dep/lib
> /usr/lib/ /usr/lib/ -lxmlwrapp
> -L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3
> -L/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../.. -lstdc++ -lm -lc
> -lgcc_s /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtendS.o
> /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crtn.o -pthread
> -Werror -Wall -g -O2 -Wl,-soname -Wl,mylibrary.0 -o .libs/mylibrary.0.0.0
> (cd .libs && rm -f mylibrary.0 && ln -s mylibrary.0.0.0 mylibrary.0)
> (cd .libs && rm -f mylibrary && ln -s mylibrary.0.0.0 mylibrary)
> creating
> (cd .libs && rm -f && ln -s ../
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -pthread -Werror -Wall
> -g -O2 -o mytestsuite -R/<somepath>/dep/lib mytestsuite.o
> ../../src/mylibrary/ -L/<somepath>/dep/lib
> -lboost_unit_test_framework
> g++ -pthread -Werror -Wall -g -O2 -o .libs/mytestsuite mytestsuite.o
> ../../src/mylibrary/.libs/mylibrary -L/<somepath>/dep/lib -L/usr/lib
> /usr/lib/ /usr/lib/ -lm -lpthread -lz -lxmlwrapp
> -lboost_unit_test_framework -Wl,--rpath
> -Wl,/<somepath>/release/product/lib -Wl,--rpath -Wl,/<somepath>/dep/lib
> creating mytestsuite
> ../../src/mylibrary/mytestsuite
> *** No errors detected
> --------------------
> Richard
> Richard Newman wrote:
>>I appreciate your reply.
>>With it coming from an RPM, I think I can only tell if it were linked in
>>multi-thread mode by looking at its dependencies (there is no _mt_gcc
>>type suffixes on the libraries since they are just copied into /usr/lib
>>by the RPM). The dependencies include libpthread, so I'm going to
>>assume from that multi-threaded mode has been used to build the
>>libraries for the package. When we built Boost directly, we generally
>>used the _mt_gcc version.
>>Nominally, we don't need pthreads right now in our test case as none of
>>the tests seem to directly invoke mutexes. However, the library we are
>>building the test suite to cover does include mutex support. (We
>>recently began to use the Boost test framework to automate unit testing
>>and so we have been adding tests as we touch code during refactors, etc.
>>so our test coverage is not at all complete yet). In any case, linking
>>with pthread on my FC4/gcc4.0.1/boost1.32.0-6rpm worked fine. I do
>>think though that a library reference might be to blame, I just don't
>>know where to look.
>>I could certainly do a trivial single test case. However, I had avoided
>> such an approach because to compare apples to apples, the best is to
>>leave everything in place and comment out all the unit tests, adding
>>back in a single one. From there though, I could start to tear apart
>>the make files and note when things changed. I'm probably left with
>>that as the only real diagnostic now; I was hoping the symptoms were
>>indicative of some library, etc., missing that I was ignorant of.
>>Gennadiy Rozental wrote:
>>>>Any advice to proceed and repair? We'd like very much to be able to use
>>>>these RPMs than reverting back to our previous homegrown approach.
>>>I don't think I could be of too much help here. Couple notes though. All
>>>boost libraries could be built both in single and multi-thread mode. Could
>>>you choose one to use? Which one are you using now? Does it anything to do
>>>with what you are doing - Did you try to run trivial single test case
>>>module? Why do you need to link with pthreads at all?

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at