Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy

[David F. <fa...@kd...>]

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