Problem with shared_ptr and pthreads_mutex_lock
I've run into a strange problem using shared_ptr which I've reduced to the following simple case. #include <tr1/memory> class X { public: typedef std::tr1::shared_ptr<X> Ptr; int x; }; int main(int argc, char *argv[]) { for (int i = 0; i < 100; i++) { X::Ptr pX(new X); } return EXIT_SUCCESS; } Compiling with g++ 4.0.1 on a Debian system with "-O0 -g -fno-inline -DDEBUG". When this program is run under Valgrind (MemCheck) repeated messages like the following occur. ==9950== Conditional jump or move depends on uninitialized value(s) ==9950== at 0x1BBB6D9A: pthread_mutex_lock (in /lib/tls/libpthread-2.3.5.so) ==9950== by 0x1BB56C75: pthread_mutex_lock (in /lib/tls/libc-2.3.5.so) ==9950== by 0x804BF29: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:510) ==9950== by 0x8057ACD: std::tr1::_Sp_counted_base::release() (boost_shared_ptr.h:148) ==9950== by 0x8057B14: std::tr1::shared_count::~shared_count() (boost_shared_ptr.h:266) ==9950== by 0x806B1F4: std::tr1::shared_ptr<X>::~shared_ptr() (boost_shared_ptr.h:474) ==9950== by 0x806B1C9: main (main.cpp:30) ==9950== In the real code this leads to either a hang or an assert in pthread_mutex_lock. If the created pointer is put in a container then this doesn't seem to happen although the problem may just be postponed (the program is never able to complete). I've tried Electric Fence and dmalloc but neither told me anything useful. The hang or assert occurs at the same point every time unless the program is changed or the environment changes (e.g., running under Valgrind). It seems consistent with uninitialized memory. But why? And more important, what can I do about it? Any help would be greatly appreciated! Kurt Kohler Alpha Omega Computer Systems Corvallis, OR
Kurt Kohler wrote:
I've run into a strange problem using shared_ptr which I've reduced to the following simple case.
#include <tr1/memory>
class X { public: typedef std::tr1::shared_ptr<X> Ptr;
int x; };
int main(int argc, char *argv[]) { for (int i = 0; i < 100; i++) { X::Ptr pX(new X); }
return EXIT_SUCCESS; }
Compiling with g++ 4.0.1 on a Debian system with "-O0 -g -fno-inline -DDEBUG". When this program is run under Valgrind (MemCheck) repeated messages like the following occur.
==9950== Conditional jump or move depends on uninitialized value(s) ==9950== at 0x1BBB6D9A: pthread_mutex_lock (in /lib/tls/libpthread-2.3.5.so) ==9950== by 0x1BB56C75: pthread_mutex_lock (in /lib/tls/libc-2.3.5.so) ==9950== by 0x804BF29: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:510) ==9950== by 0x8057ACD: std::tr1::_Sp_counted_base::release() (boost_shared_ptr.h:148)
You seem to be using libstdc++'s implementation of shared_ptr; if the problem doesn't occur with boost::shared_ptr, a better place to ask this question would be libstdc++'s own mailing list.
Your reply actually help me fix the problem! I wasn't aware that the boost and tr1 versions of shared_ptr are different. When I changed my code to use the boost version, the problem went away. I'll have to see if I can figure out where to report the bug. Thanks! Peter Dimov wrote:
Kurt Kohler wrote:
I've run into a strange problem using shared_ptr which I've reduced to the following simple case.
#include <tr1/memory>
class X { public: typedef std::tr1::shared_ptr<X> Ptr;
int x; };
int main(int argc, char *argv[]) { for (int i = 0; i < 100; i++) { X::Ptr pX(new X); }
return EXIT_SUCCESS; }
Compiling with g++ 4.0.1 on a Debian system with "-O0 -g -fno-inline -DDEBUG". When this program is run under Valgrind (MemCheck) repeated messages like the following occur.
==9950== Conditional jump or move depends on uninitialized value(s) ==9950== at 0x1BBB6D9A: pthread_mutex_lock (in /lib/tls/libpthread-2.3.5.so) ==9950== by 0x1BB56C75: pthread_mutex_lock (in /lib/tls/libc-2.3.5.so) ==9950== by 0x804BF29: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:510) ==9950== by 0x8057ACD: std::tr1::_Sp_counted_base::release() (boost_shared_ptr.h:148)
You seem to be using libstdc++'s implementation of shared_ptr; if the problem doesn't occur with boost::shared_ptr, a better place to ask this question would be libstdc++'s own mailing list.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I've verified to my own satisfaction that the gcc and boost versions are *not* the same, since the boost version doesn't have the bug I was seeing. I'm not exactly sure where to report stdc++ library bugs, but I subscribed to the mailing list so I assume I'll find out. Kurt John Maddock wrote:
#include <tr1/memory>
Isn't that the gcc implementation of shared_ptr? Or is it the same as the Boost version? Maybe this would be better filed as a gcc stdlib bug.
John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
John Maddock -
Kurt Kohler -
Peter Dimov