Re: [Boost-users] Auto unit test suite hangs due to locked mutex

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/libpthread.so.0
#2  0x0064ac84 in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0
#3  0x003fd840 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#4  0x0036e8ea in scoped_lock (this=0x8aab67c, m=@0x3fd840) at 
lwm_pthreads.hpp:72
#5  0x0036e8ea in scoped_lock (this=0xfeedd910, m=@0x8aab67c) at 
lwm_pthreads.hpp:72
#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 
call_traits.hpp:103
#11 0x00b45d45 in boost::unit_test::ut_detail::normalize_test_case_name 
() from /usr/lib/libboost_unit_test_framework.so.1
#12 0x00b46018 in 
std::for_each<std::_List_iterator<boost::unit_test::test_case*, 
boost::unit_test::test_case*&, boost::unit_test::test_case**>, void 
(*)(boost::unit_test::test_case*)> () from 
/usr/lib/libboost_unit_test_framework.so.1
#13 0x00b459cb in boost::unit_test::test_suite::~test_suite () from 
/usr/lib/libboost_unit_test_framework.so.1
#14 0x00b46ddc in main () from /usr/lib/libboost_unit_test_framework.so.1
#15 0x00423ad4 in __libc_start_main () from /lib/tls/libc.so.6
#16 0x08048a3d in _start ()
(gdb)
--------------------------

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

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).
> 
> BOOST_AUTO_UNIT_TEST(TrivialTest)
> {
> 	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 mylibrary.la -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/mylibrary.la 
> .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/libxslt.so /usr/lib/libxml2.so -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 mylibrary.la
> (cd .libs && rm -f mylibrary.la && ln -s ../mylibrary.la mylibrary.la)
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -pthread -Werror -Wall 
> -g -O2   -o mytestsuite -R/<somepath>/dep/lib mytestsuite.o 
> ../../src/mylibrary/mylibrary.la -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/libxslt.so /usr/lib/libxml2.so -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.
>>
>>Thanks,
>>Richard
>>
>>
>>
>>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?
>>>
>>>Gennadiy