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:jsew...@acm.org]
Sent: Dienstag, 25. November 2014 13:40
To: valgrind-users@lists.sourceforge.net; 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
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
