On Fri, May 15, 2009 at 10:06 AM, Andy Howell <andyhow...@austin.rr.com> wrote: > Bart Van Assche wrote: >> >> On Fri, May 15, 2009 at 9:33 AM, Andy Howell <andyhow...@austin.rr.com> >> 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. > > 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.
No problem. And thanks for reporting the assertion failure. By this time the assertion failure you reported has been fixed both on the trunk and on the Valgrind 3.4.x branch. Bart. ------------------------------------------------------------------------------ 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
