Discussion:
boost:shared_ptr destructor, SIGBUS, MIPS 64
sumanth krishna
2012-01-03 18:04:09 UTC
Permalink
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.
Peter Dimov
2012-01-03 18:24:54 UTC
Permalink
Post by sumanth krishna
#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.
sumanth krishna
2012-01-04 04:05:42 UTC
Permalink
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 ?
Post by sumanth krishna
#8 0x0000000120068b64 in C::~C (this=0x1200a8e70, __in_chrg=<value
Post by sumanth krishna
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
http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
Peter Dimov
2012-01-04 22:08:55 UTC
Permalink
Post by sumanth krishna
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.
Post by sumanth krishna
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.
sumanth krishna
2012-01-05 11:30:33 UTC
Permalink
@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
Post by Peter Dimov
Post by sumanth krishna
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
Post by sumanth krishna
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
http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
Loading...