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