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
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
-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 -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