Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Date: Fri, 8 Nov 2013 08:20:24 +0100 Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy From: magnus.ref...@gmail.com To: saur...@hotmail.com CC: valgrind-users@lists.sourceforge.net That is most definitely wrong. Thread 1 destroys a locked mutex, and according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html : Attempting to destroy a locked mutex results in undefined behavior. BR Magnus Reftel You are right. But I was wrong about what was going on. The mutex *is* destroyed after unlocking. Sorry. I guess I will put in a suppression for now. saurabh -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
On Fri, 2013-11-08 at 19:20 +, Saurabh T wrote:
Date: Fri, 8 Nov 2013 08:20:24 +0100
Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with
pthread_mutex_destroy
From: magnus.ref...@gmail.com
To: saur...@hotmail.com
CC: valgrind-users@lists.sourceforge.net
That is most definitely wrong. Thread 1 destroys a locked mutex, and
according to
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html
:
Attempting to destroy a locked mutex results in undefined behavior.
BR
Magnus Reftel
You are right. But I was wrong about what was going on. The mutex *is*
destroyed after unlocking.
Sorry. I guess I will put in a suppression for now.
I think this is a regression in 3.9.0 caused by revision 13642 which:
Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy
with initializers as argument Helgrind (incorrectly) reports errors.
The problem is that the pthread_mutex_destroy wrapper function is
comparing the mutex with PTHREAD_MUTEX_INITIALIZER to detect if mutex
was initialised using PTHREAD_MUTEX_INITIALIZER
rather than with pthread_mutex_init.
The regression should be fixed (no test case :) with:
Index: helgrind/hg_intercepts.c
===
--- helgrind/hg_intercepts.c(revision 13711)
+++ helgrind/hg_intercepts.c(working copy)
@@ -470,7 +470,9 @@ PTH_FUNC(int, pthreadZumutexZudestroy, // pthread_
if (mutex != NULL) {
static const pthread_mutex_t mutex_init = PTHREAD_MUTEX_INITIALIZER;
+ VALGRIND_HG_DISABLE_CHECKING(mutex, sizeof(*mutex));
mutex_is_init = my_memcmp(mutex, mutex_init, sizeof(*mutex)) == 0;
+ VALGRIND_HG_ENABLE_CHECKING(mutex, sizeof(*mutex));
} else {
mutex_is_init = 0;
}
Now, is this really a regression ? It might in fact be a feature :).
If there is no synchronisation mechanism between a thread doing
lock/unlock and another thread calling pthread_mutex_destroy, then
if the thread doing lock/unlock is slow, the mutex could be destroyed
while it is locked (or even before the locking thread has started to
lock it. And then the locking thread might try to lock a destroyed
mutex.
Philippe
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy From: philippe.waroqui...@skynet.be To: saur...@hotmail.com CC: valgrind-users@lists.sourceforge.net Date: Fri, 8 Nov 2013 22:46:28 +0100 I think this is a regression in 3.9.0 caused by revision 13642 which: Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy with initializers as argument Helgrind (incorrectly) reports errors. The problem is that the pthread_mutex_destroy wrapper function is comparing the mutex with PTHREAD_MUTEX_INITIALIZER to detect if mutex was initialised using PTHREAD_MUTEX_INITIALIZER rather than with pthread_mutex_init. Philippe, Thank you for the patch, it worked. For what it's worth, the situation that you mention cannot happen for my code. saurabh Now, is this really a regression ? It might in fact be a feature :). If there is no synchronisation mechanism between a thread doing lock/unlock and another thread calling pthread_mutex_destroy, then if the thread doing lock/unlock is slow, the mutex could be destroyed while it is locked (or even before the locking thread has started to lock it. And then the locking thread might try to lock a destroyed mutex. Philippe -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996== at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996== by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) snip ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996== at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996== by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) snip ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996== at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) snip This was not a problem with 3.8.1 so appears to be a regression or new bug. saurabh -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996==at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996==by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) snip ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996==at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996==by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996==by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996==by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) snip ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996==at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) snip Can you prove that the destroy cannot happen during the unlock? This was not a problem with 3.8.1 so appears to be a regression or new bug. ... or a fix, which detects an actual problem in the code :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: saur...@hotmail.com Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy Date: Thu, 7 Nov 2013 17:25:57 +0100 On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: snip Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh This was not a problem with 3.8.1 so appears to be a regression or new bug. ... or a fix, which detects an actual problem in the code :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
On 7 November 2013 18:21, Saurabh T saur...@hotmail.com wrote: From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: saur...@hotmail.com Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy Date: Thu, 7 Nov 2013 17:25:57 +0100 On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: snip Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh That is most definitely wrong. Thread 1 destroys a locked mutex, and according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html : Attempting to destroy a locked mutex results in undefined behavior. BR Magnus Reftel -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
