Bart Van Assche wrote:
> On Fri, May 15, 2009 at 9:33 AM, Andy Howell <[email protected]> wrote:
>> Hello,
>>
>> I'm seeing this with 3.4.1 compiled on fedora 9.
>>
>> Just before that I see:
>>
>> ==14457== Mutex reinitialization: mutex 0x4c621a8, recursion count 0, owner
>> 0.
>> ==14457== at 0x4A0B4A4: pthread_mutex_init (in
>> /usr/lib64/valgrind/amd64-linux/vgpreload_drd.so)
>> ==14457== by 0x546DCE: Mutex::create(Mutex::MutexType) (thread.cpp:1023)
>> ==14457== by 0x4DDA85: AsyncDNSImpl::init(Select*, ThreadAccess, unsigned
>> int)
>> (async_dns.cpp:1518)
>> ==14457== by 0x4DE47E: AsyncDNSImpl::create(Select*, EventManager*,
>> ThreadAccess,
>> unsigned int) (async_dns.cpp:87)
>> ==14457== by 0x4E2FAF: AsyncDNS::create(Select*, EventManager*,
>> ThreadAccess, unsigned
>> int) (async_dns.cpp:64)
>> ==14457== by 0x412809: Agent::init(int, char**) (agent.cpp:1838)
>> ==14457== by 0x414C77: main (agent.cpp:2559)
>>
>> ==14457== mutex 0x4c621a8 was first observed at:
>> ==14457== at 0x4A0B4A4: pthread_mutex_init (in
>> /usr/lib64/valgrind/amd64-linux/vgpreload_drd.so)
>> ==14457== by 0x546D9E: Mutex::create(Mutex::MutexType) (thread.cpp:1002)
>> ==14457== by 0x4DDA85: AsyncDNSImpl::init(Select*, ThreadAccess, unsigned
>> int)
>> (async_dns.cpp:1518)
>> ==14457== by 0x4DE47E: AsyncDNSImpl::create(Select*, EventManager*,
>> ThreadAccess,
>> unsigned int) (async_dns.cpp:87)
>> ==14457== by 0x4E2FAF: AsyncDNS::create(Select*, EventManager*,
>> ThreadAccess, unsigned
>> int) (async_dns.cpp:64)
>> ==14457== by 0x412809: Agent::init(int, char**) (agent.cpp:1838)
>> ==14457== by 0x414C77: main (agent.cpp:2559)
>>
>> ==14457== ??? mutex 0x4c621a8: type changed from 3 into 1
>>
>> Looks like drd thinks the mutex type is changing from a default type to a
>> recursive type
>> mutex. I don't understand why it thinks the mutex is being re-initialized.
>> Both call
>> stacks contain the same functions and line numbers. In my code, this
>> initialization is
>> only done once. Any ideas?
>
> Please look more carefully: the second call stack refers to file
> thread.cpp, line 1002, while the first call stack refers to file
> thread.cpp line 1023. So the above message most likely reports what it
> says: mutex reinitialization.
>
Bart,
You confirmed its time for me to call it a night. I double checked them
before sending
the mail, but was obviously too bleary-eyed to catch it. Thanks for your help.
Regards,
Andy
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
