Re: [Boost-users] Compatibility between shared_ptr and Rational RoseRT

On 4/26/05, Ross Manges wrote:

...

Attaching the code (in whatever form is convenient to you) is fine. OK, I've attached some sample code I made up to show the kind of problems I'm having (the code doesn't do anything useful). Running this code results in the backtrace below. I am aware that this code breaks the condition that the shared_ptr needs to have exclusive writing modifications; however, I am unsure how to fix the code to make it correct. Please let me know if you have any suggestions, thanks! (BTW, I'm running against the Boost CVS which I downloaded on Fri, Apr 22nd; if I run against version 1_32, the backtrace is in the scope_lock instead of atomic_increment)

some info about my system: Red Hat Enterprise Linux 3, running 2.4.21-4.ELsmp (on a dual-processor dell with xeon's, if that matters)

and here's the backtrace: (gdb) bt #0 0x0804a703 in atomic_increment (pw=0x21006) at sp_counted_base_gcc_x86.hpp:59 #1 0x0804a655 in boost::detail::sp_counted_base::add_ref_copy (this=0x21002) at sp_counted_base_gcc_x86.hpp:133 #2 0x0804a4d7 in boost::detail::shared_count::operator= (this=0xb191cde8, r=@0xb731e004) at shared_count.hpp:181 #3 0x08049a58 in boost::shared_ptr<Element>::operator= (this=0xb191cde4, r=@0xb731e000) at shared_ptr.hpp:148 #4 0x0804b089 in SimpleQueue::pop (this=0x804f290) at ../SimpleQueue.cpp:22 #5 0x080494ef in CommonThread::operator() (this=0x8050470) at ../CommonThread.cpp:11 #6 0x0804a06d in boost::detail::function::void_function_obj_invoker0::invoke (function_obj_ptr= {obj_ptr = 0x8050470, const_obj_ptr = 0x8050470, func_ptr = 0x8050470, data = "p"}) at function_template.hpp:136 #7 0xb75ce283 in boost::thread_group::size () from /home/auser/devel/boost_cvs_install/lib/libboost_thread-gcc-mt-1_32.so.1.32.0 #8 0xb7493e21 in pthread_start_thread () from /lib/i686/libpthread.so.0 #9 0xb743208a in clone () from /lib/i686/libc.so.6

In SimpleQueue::pop, you call Queue.empty() without locking the mutex. Move your scoped lock before the if (!Queue.empty ()) check and all is well. I've verified this on a 2-way Xeon box running an almost-identical kernel. -- Caleb Epstein caleb dot epstein at gmail dot com