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

From: Richard Newman (richard_at_[hidden])
Date: 2005-08-11 13:22:53

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