From: Saurabh T <sa...@ho...> - 2013-11-07 16:23:03
|
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 |
From: David F. <fa...@kd...> - 2013-11-07 16:26:10
|
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...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |
From: Saurabh T <sa...@ho...> - 2013-11-07 17:21:51
|
---------------------------------------- > From: fa...@kd... > To: val...@li... > CC: sa...@ho... > 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...@kd..., http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > |
From: Magnus R. <mag...@gm...> - 2013-11-08 07:20:32
|
On 7 November 2013 18:21, Saurabh T <sa...@ho...> wrote: > ---------------------------------------- >> From: fa...@kd... >> To: val...@li... >> CC: sa...@ho... >> 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 |
From: Saurabh T <sa...@ho...> - 2013-11-08 19:20:39
|
---------------------------------------- > Date: Fri, 8 Nov 2013 08:20:24 +0100 > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > From: mag...@gm... > To: sa...@ho... > CC: val...@li... > > 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 |
From: Philippe W. <phi...@sk...> - 2013-11-08 21:45:12
|
On Fri, 2013-11-08 at 19:20 +0000, 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: mag...@gm... > > To: sa...@ho... > > CC: val...@li... > > > > 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 |
From: Saurabh T <sa...@ho...> - 2013-11-08 23:06:24
|
---------------------------------------- > Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy > From: phi...@sk... > To: sa...@ho... > CC: val...@li... > 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 > > |