I've run into a strange problem using shared_ptr which I've reduced to
the following simple case.
#include
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
