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: 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=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
