valgrind-users

[Valgrind-users] helgrind and c++ atomic_flag

[John P. <Joh...@us...>]

Hello!

When run in helgrind, the C++ example programs at

    en.cppreference.com/w/cpp/atomic/atomic_flag

and

    www.cplusplus.com/reference/atomic/atomic_flag/

report a bunch of possible data races. For instance,

    ==24483== Possible data race during read of size 1 at 0x6051F1 by
    thread #3
    ==24483== Locks held: none
    ==24483==    at 0x400E8F: test_and_set (atomic_base.h:176)
    ==24483==    by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11)
    ...
    ==24483== This conflicts with a previous write of size 1 by thread
    #2
    ==24483== Locks held: none
    ==24483==    at 0x400EE6: clear (atomic_base.h:193)
    ==24483==    by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14)

Is it correct to conclude that these are false positives? I found a
lot of discussion in the mailing list on atomic operations but nothing
"recent" seemed to address the C++ standard library.

regards
john perry

-- 
John Perry, PhD + Associate Professor of Mathematics
Undergraduate Program Lead, Mathematics BS
University of Southern Mississippi
School of Physical and Metaphysical Sciences
(i.e., School of Mathematics and Natural Sciences)


Contrariwise, if it was so, it might be, and if it were so, it would
be, but as it isn't, it ain't. That's logic. -- Tweedledee, Through the
Looking Glass

Re: [Valgrind-users] helgrind and c++ atomic_flag

[Tom H. <to...@co...>]

On 25/09/2018 05:44, John Perry wrote:

> When run in helgrind, the C++ example programs at
> 
>      en.cppreference.com/w/cpp/atomic/atomic_flag
> 
> and
> 
>      www.cplusplus.com/reference/atomic/atomic_flag/
> 
> report a bunch of possible data races. For instance,
> 
>      ==24483== Possible data race during read of size 1 at 0x6051F1 by
>      thread #3
>      ==24483== Locks held: none
>      ==24483==    at 0x400E8F: test_and_set (atomic_base.h:176)
>      ==24483==    by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11)
>      ...
>      ==24483== This conflicts with a previous write of size 1 by thread
>      #2
>      ==24483== Locks held: none
>      ==24483==    at 0x400EE6: clear (atomic_base.h:193)
>      ==24483==    by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14)
> 
> Is it correct to conclude that these are false positives? I found a
> lot of discussion in the mailing list on atomic operations but nothing
> "recent" seemed to address the C++ standard library.

I don't believe helgrind makes any attempt to observe atomic
operations so it is entirely unaware of them and of any effect
they might have on the thread correctness of a program.

It would be hard to do because where the compiler is able to
generate direction instructions for the atomic there will be no
function call to intercept, and as there won't necessarily be a
one-one mapping from atomic operations to CPU instructions it
is hard to determine what the original operation was by
observing the instruction stream.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] helgrind and c++ atomic_flag

[John P. <Joh...@us...>]

> On Sep 25, 2018, at 7:02 AM, Tom Hughes <to...@co...> wrote:
> 
> I don't believe helgrind makes any attempt to observe atomic
> operations so it is entirely unaware of them and of any effect
> they might have on the thread correctness of a program.
> 
> It would be hard to do because where the compiler is able to
> generate direction instructions for the atomic there will be no
> function call to intercept, and as there won't necessarily be a
> one-one mapping from atomic operations to CPU instructions it
> is hard to determine what the original operation was by
> observing the instruction stream.

Thank you! This comes as a huge relief, because I first noticed the issue in a program I was writing where I used that approach and worried I was doing something very, very bad. Now I can rest easy. Or at least easier.

regards
john perry

-- 
John Edward Perry, III
Associate Professor, Dept of Mathematics, University of Southern Mississippi
Undergraduate Program Lead, Mathematics BS
joh...@us...
A man with no regrets has either no past or no conscience.

Re: [Valgrind-users] helgrind and c++ atomic_flag

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

On mardi 25 septembre 2018 16:17:48 CEST John Perry wrote:
> > On Sep 25, 2018, at 7:02 AM, Tom Hughes <to...@co...> wrote:
> > 
> > I don't believe helgrind makes any attempt to observe atomic
> > operations so it is entirely unaware of them and of any effect
> > they might have on the thread correctness of a program.
> > 
> > It would be hard to do because where the compiler is able to
> > generate direction instructions for the atomic there will be no
> > function call to intercept, and as there won't necessarily be a
> > one-one mapping from atomic operations to CPU instructions it
> > is hard to determine what the original operation was by
> > observing the instruction stream.
> 
> Thank you! This comes as a huge relief, because I first noticed the issue in a program I was writing where I used that approach and worried I was doing something very, very bad. Now I can rest easy. Or at least easier.

You want to use TSAN (thread-sanitizer) instead (preferably with clang and libc++, in my experience), which supports atomic operations.

Sorry for advertising a competing solution on the valgrind mailing-list ;-)
I admit I'm much less of a helgrind fan since tsan started to work well.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5