boost:shared_ptr destructor, SIGBUS, MIPS 64
I am using a STL list of boost shared pointer in my code and and it randomly dumps core. Below is the code snippet and the core stack. class A () { virtual ~A(); string getsomestring(); } class B: public A { } typedef shared_ptr<A> A_ptr; class C // singelton class { public: getList(list <A_ptr>& temp_list) { list<A_ptr>::iterator itr = _inv.begin(); for( ; itr != _inv.end(); itr++ ) { temp_list.push_back( (*itr) ); } getListContent ( list<string>& str_list) { list<A_ptr>::iterator itr = _inv.begin(); for( ; itr != _inv.end(); itr++ ) { str_list.push_back( (*itr)->getsomestring() ); } } private: list <A_ptr> _inv; } main() { C *c= new C; // create an instance ( its a singleton class) // On creating an instance of C, the private member variable inventory is populated. // inventory.push_back(A_ptr(new FRU ( fvar ))) thread 1 { list<A_ptr> var1; c->getList(var1); list <string> var2; c->getListContent(var2); } // End of thread delete c; } // end of main Now this code works fine for some iterations and then dumps core with the following stack ###################### Thread 1 (Thread 0x55567f7af0 (LWP 23773)): #0 0x0000000120038ecc in boost::detail::atomic_decrement (pw=0xa) sysroot/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_mips.hpp:66 #1 0x0000000120038f44 in boost::detail::sp_counted_base::release (this=0x2) #2 0x00000001200390ac in boost::detail::shared_count::~shared_count (this=0x1200b08d8, __in_chrg=<value optimized out>) #3 0x000000012003eaf4 in boost::shared_ptr<A>::~shared_ptr (this=0x1200b08d0, __in_chrg=<value optimized out>) #4 0x000000012003eb4c in __gnu_cxx::new_allocator<boost::shared_ptr<A>
::destroy (this=0xffffeaf640, __p=0x1200b08d0)
#5 0x000000012003c9e0 in std::_List_base<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::_M_clear (this=0x1200a8ee8) #6 0x000000012003b4ac in std::_List_base<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::~_List_base (this=0x1200a8ee8, __in_chrg=<value optimized out>) #7 0x000000012003a0e8 in std::list<boost::shared_ptr<A>, std::allocator<boost::shared_ptr<A> > >::~list (this=0x1200a8ee8, __in_chrg=<value optimized out>) #8 0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value optimized out>) ###################################################### This code is cross compiled for MIPS64 arch on linux x86_64 machine and is running on a 64 bit MIPS machine. I am not sure why it is dumping core. It dumps core giving a *SIGBUS* error. Do i have to specifically handle the delete operation of the List ? I am using the default destructor for "C" class and there is no pointers in the class A and Class A also doesnt have anything in its destructor, no memory allocations are done in Class A. Any suggestions regarding this problem would be highly helpful.
sumanth krishna wrote:
#8 0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value optimized out>)
Is it possible for a thread to still be calling c->getList when ~C is executed? Based on your (pseudo)code, a number of temporary std::list<shared_ptr<A>> instances are created and destroyed without a problem before C's member, so list destruction on its own seems to work fine.
Peter Dimov Wrote: ################################################################## Is it possible for a thread to still be calling c->getList when ~C is executed? Based on your (pseudo)code, a number of temporary std::list<shared_ptr<A>> instances are created and destroyed without a problem before C's member, so list destruction on its own seems to work fine. ######################################################################## C is a singleton class and from the logs i can see that the other threads have exited before the destructor of C is called. Even if the thread calls c->getList after ~C is executed, then also it should not cause a problem because until all the instances are deleted and reference count of the shared pointers reaches zero the memory for the allocated class should not be deleted. Or is there a race condition when both the C class is decrementing the reference count of the shared pointer and the threads reference count are being decremented simultaneously ? But then again from the stack the reference count decrementing is an atomic operation, so should not be an issue right ? On Tue, Jan 3, 2012 at 11:54 PM, Peter Dimov <pdimov@pdimov.com> wrote:
sumanth krishna wrote:
#8 0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value
optimized out>)
Is it possible for a thread to still be calling c->getList when ~C is executed?
Based on your (pseudo)code, a number of temporary std::list<shared_ptr<A>> instances are created and destroyed without a problem before C's member, so list destruction on its own seems to work fine. ______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
sumanth krishna wrote:
C is a singleton class and from the logs i can see that the other threads have exited before the destructor of C is called.
Well, in this case you should try to isolate a complete program that crashes and post it here.
Even if the thread calls c->getList after ~C is executed, then also it should not cause a problem because until all the instances are deleted and reference count of the shared pointers reaches zero the memory for the allocated class should not be deleted.
No, destroying a shared_ptr in one thread and copying it from another doesn't work. Even if it did, destroying a std::list in one thread and iterating over it from another doesn't work either. If you access an object from more than one thread, all accesses must be read (non-modifying) accesses.
@Peter: You were right, one of the threads was explicitly deleting the list and hence the cause for the crash. Thanks for your help. -Samm On Thu, Jan 5, 2012 at 3:38 AM, Peter Dimov <pdimov@pdimov.com> wrote:
sumanth krishna wrote:
C is a singleton class and from the logs i can see that the other threads have exited before the destructor of C is called.
Well, in this case you should try to isolate a complete program that crashes and post it here.
Even if the thread calls c->getList after ~C is executed, then also it
should not cause a problem because until all the instances are deleted and reference count of the shared pointers reaches zero the memory for the allocated class should not be deleted.
No, destroying a shared_ptr in one thread and copying it from another doesn't work. Even if it did, destroying a std::list in one thread and iterating over it from another doesn't work either. If you access an object from more than one thread, all accesses must be read (non-modifying) accesses. ______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
participants (2)
-
Peter Dimov
-
sumanth krishna