shared_ptr use_count in multi threaded environment
I've been experiencing trouble with shared_ptrs in a multithreaded environment. First, I noticed that the ref count wasn't being locked when updated by multiple threads (shared_count.hpp). I recompiled the boost library with BOOST_HAS_THREADS defined the user.hpp, and now I can verify that the scoped_lock is being used, but I'm still seeing the same kind of problems. The traces happen in different places each time, but in general it appears that the ref count is being decremented to zero inappropriately, which in turn sometimes causes the dreaded "assert px != 0" message. See the example traces below. Please let me know if you have any suggestions on how I might proceed to debug this problem. Thanks! message that preceeded "trace A": main: /.../boost-1_32/boost/shared_ptr.hpp:253: T* boost::shared_ptr<T>::operator->() const [with T = Connector]: Assertion `px != 0' failed. ======== trace A with px != 0 assert ============ #0 0xb70d6e01 in kill () from /lib/i686/libc.so.6 #1 0xb6f641ed in pthread_kill () from /lib/i686/libpthread.so.0 #2 0xb6f6458b in raise () from /lib/i686/libpthread.so.0 #3 0xb70d6ba4 in raise () from /lib/i686/libc.so.6 #4 0xb70d805d in abort () from /lib/i686/libc.so.6 #5 0xb70cfe99 in __assert_fail () from /lib/i686/libc.so.6 #6 0xb73aac75 in boost::shared_ptr<Connector>::operator-> ( this=0xb6710d24) at shared_ptr.hpp:253 #7 0xb73a98b1 in Listener::run ( this=0x8089af0) at Adapter.cpp:974 #8 0xb74d37be in ost::ThreadImpl::ThreadExecHandler (th=0x8089af0) at thread.cpp:1110 #9 0xb74d29bf in ccxx_exec_handler (th=0x8089af0) at thread.cpp:1136 #10 0xb6f61e21 in pthread_start_thread () from /lib/i686/libpthread.so.0 #11 0xb718c08a in clone () from /lib/i686/libc.so.6 ======== trace B, no px != 0 assert ============ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 81926 (LWP 18562)] 0xb6f62232 in pthread_mutex_lock () from /lib/i686/libpthread.so.0 (gdb) bt #0 0xb6f62232 in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #1 0xb71997ef in pthread_mutex_lock () from /lib/i686/libc.so.6 #2 0x0806bf45 in scoped_lock (this=0xb65e0b64, m=@0x27) at lwm_pthreads.hpp:72 #3 0x0806ba29 in boost::detail::sp_counted_base::add_ref_copy (this=0x1b) at shared_count.hpp:122 #4 0x0806a98d in boost::detail::shared_count::operator= (this=0xb65e0ce8, r=@0xb6c01b1c) at shared_count.hpp:400 #5 0xb73aac18 in boost::shared_ptr<Connector>::operator= ( this=0xb65e0ce4, r=@0xb6c01b18) at shared_ptr.hpp:148 #6 0xb73a974e in Listener::run ( this=0xb6c02f68) at Adapter.cpp:966 #7 0xb74d37be in ost::ThreadImpl::ThreadExecHandler (th=0xb6c02f68) at thread.cpp:1110 #8 0xb74d29bf in ccxx_exec_handler (th=0xb6c02f68) at thread.cpp:1136 #9 0xb6f61e21 in pthread_start_thread () from /lib/i686/libpthread.so.0 #10 0xb6f61fb5 in pthread_start_thread_event () from /lib/i686/libpthread.so.0 #11 0xb718c08a in clone () from /lib/i686/libc.so.6
Manges, Ross G wrote:
I've been experiencing trouble with shared_ptrs in a multithreaded environment. First, I noticed that the ref count wasn't being locked when updated by multiple threads (shared_count.hpp). I recompiled the boost library with BOOST_HAS_THREADS defined the user.hpp, and now I can verify that the scoped_lock is being used, but I'm still seeing the same kind of problems. The traces happen in different places each time, but in general it appears that the ref count is being decremented to zero inappropriately, which in turn sometimes causes the dreaded "assert px != 0" message. See the example traces below. Please let me know if you have any suggestions on how I might proceed to debug this problem. Thanks!
Two questions: - Is it possible that some parts of your code are compiled without BOOST_HAS_THREADS?
#5 0xb73aac18 in boost::shared_ptr<Connector>::operator= ( this=0xb65e0ce4, r=@0xb6c01b18) at shared_ptr.hpp:148 #6 0xb73a974e in Listener::run ( this=0xb6c02f68) at Adapter.cpp:966
- Is it possible that you are assigning to the shared_ptr<Connector> object and at the same time reading it (making a copy of it, for example) or even assigning or resetting it from a different thread?
participants (2)
-
Manges, Ross G
-
Peter Dimov