Re: [Valgrind-users] Problem with helgrind?

[Pohl, H. <har...@ad...>]

Hi,

The stack I think is wrong is the following combination:
==7704== Possible data race during read of size 4 at 0xFFEFFFE40 by thread #5 ==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==
==7704== This conflicts with a previous write of size 4 by thread #3 ==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)

As far as I understand, Thread #5 belongs to the second test case and thus cannot have a data race with thread #3 due to the pthread_join()s.

I put the annotation at the end of the while (that's what I started with). Same output.

Best regards,
	Hartmut

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Dienstag, 25. November 2014 13:40
To: val...@li...; Pohl, Hartmut
Subject: Re: [Valgrind-users] Problem with helgrind?

On 11/25/2014 10:22 AM, Pohl, Hartmut wrote:

> What confuses me is that the stack trace incorrectly reports a data 
> race between the first and the second test thread. Which is impossible 
> and makes me think that maybe the pthread_join() is incorrectly handled by helgrind?

There are a bunch of stack traces in this message.  Exactly which one is the one you think is wrong?

I don't exactly understand the test program, but this ..

>   bool wait = true;
>   do
>   {
>     wait = atomicWait.syncLoad();
>     ANNOTATE_HAPPENS_AFTER(atomicWait.getAddress());    
>   }
>   while (wait) ;

.. doesn't feel right to me.  You need to put the ANNOTATE_HAPPENS_AFTER after the end of the while loop, not inside it, because merely reading the value

>     wait = atomicWait.syncLoad();

doesn't mean the thread can go forwards.  It has to spin until that value becomes |true|.  So the h-b edge from the main thread "arrives here" after the loop, not inside it.

J