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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-08-11 22:02:24

Unfortunately (and IMO it's a critical design flaw) smart_ptr chooses 
threadness on defines level. Still you should be able to build the unit test 
framework in single threaded mode when shared_ptr wouldn't be using any 
mutexes.

Gennadiy

"Richard Newman" <richard_at_[hidden]> wrote in message 
news:ddgbg3$g28$1_at_sea.gmane.org...
>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