|
From: <oli...@on...> - 2005-03-22 11:48:05
|
Since the pthread emulation is gone I get a lot of those warnings:
==32250== Syscall param write(buf) points to uninitialised byte(s)
==32250== at 0x1B9178CB: write (in /lib/i686/libpthread-0.10.so)
==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*),
void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23)
==32250== by 0x80AE3A7: CThreadPool::Init(int,
_STL::basic_ostream<char, _STL::char_traits<char> >*, bool,
_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>
>) (../../source/libs/libcalbase/thread/threadpool.cpp:147)
==32250== by 0x805B0C4: CTestPlugin::Initialize()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:405)
==32250== by 0x8067CB0: CTestPlugin::TestPlugin()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1551)
==32250== by 0x80670C9: CTestPlugin::RunTest()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1503)
==32250== by 0x807D18C: main
(../../../source/apps/cal/test/testplugin/testplugin.cpp:106)
==32250== Address 0x52BFDA3C is on thread 1's stack
It happens almost(?) always when calling pthread_create or pthread_join.
The code for the example above looks like this:
#include <pthread.h>
class CCalThread
{
public:
CCalThread(void* func(void*), void* arg)
: _res(-1)
{
int res = pthread_create(&_id, NULL, func, arg);
if( res == 0 ) {
_res = 0;
//pthread_detach(_id);
}
}
~CCalThread() {}
int _res;
private:
pthread_t _id;
};
And I am also always getting this memory leak:
==32250== 8160 bytes in 1 blocks are definitely lost in loss record 13
of 14
==32250== at 0x1B901538: malloc (vg_replace_malloc.c:130)
==32250== by 0x1B9134DE: __pthread_initialize_manager (in
/lib/i686/libpthread-0.10.so)
==32250== by 0x1B913A4B: pthread_create@@GLIBC_2.1 (in
/lib/i686/libpthread-0.10.so)
==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*),
void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23)
==32250== by 0x80AE3A7: CThreadPool::Init(int,
_STL::basic_ostream<char, _STL::char_traits<char> >*, bool,
_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>
>) (../../source/libs/libcalbase/thread/threadpool.cpp:147)
==32250== by 0x805B0C4: CTestPlugin::Initialize()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:405)
==32250== by 0x8067CB0: CTestPlugin::TestPlugin()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1551)
==32250== by 0x80670C9: CTestPlugin::RunTest()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1503)
==32250== by 0x807D18C: main
(../../../source/apps/cal/test/testplugin/testplugin.cpp:106)
I just don't unterstand it, because all thread are being exited
successfully and pthread_exit is always called. I thought it might have
something to do with the join state, but they aren't even joinable.
It's the same code as shown above and adding a pthread_detach there
didn't help either.
Maybe someone out there know how to fix this warnings...or are those
supression candidates?
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-22 14:35:14
|
On Tue, 22 Mar 2005 oli...@on... wrote: > Since the pthread emulation is gone I get a lot of those warnings: > > ==32250== Syscall param write(buf) points to uninitialised byte(s) > ==32250== at 0x1B9178CB: write (in /lib/i686/libpthread-0.10.so) > ==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*), > void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23) That looks familiar, I've seen similar ones in pthreaded programs. > ==32250== 8160 bytes in 1 blocks are definitely lost in loss record 13 > of 14 > ==32250== at 0x1B901538: malloc (vg_replace_malloc.c:130) > ==32250== by 0x1B9134DE: __pthread_initialize_manager (in > /lib/i686/libpthread-0.10.so) > ==32250== by 0x1B913A4B: pthread_create@@GLIBC_2.1 (in > /lib/i686/libpthread-0.10.so) > ==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*), > void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23) > > I just don't unterstand it, because all thread are being exited > successfully and pthread_exit is always called. I thought it might have > something to do with the join state, but they aren't even joinable. > It's the same code as shown above and adding a pthread_detach there > didn't help either. It's likely a bug in the pthreads library. > Maybe someone out there know how to fix this warnings...or are those > supression candidates? I believe so, for both of them. N |
|
From: Jeremy F. <je...@go...> - 2005-03-22 17:44:39
|
Nicholas Nethercote wrote:
> It's likely a bug in the pthreads library.
It's just uninitialized padding in a structure being written to a pipe;
it isn't really a bug.
>> Maybe someone out there know how to fix this warnings...or are those
>> supression candidates?
>
>
> I believe so, for both of them.
There are some suppressions for these already, but there seem to be lots
of variations.
J
|