Boost logo

Boost :

Subject: Re: [boost] [thread] Address sanitizer failures on marshall-mac
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-03-08 11:07:03

On 8 Mar 2014 at 19:18, Andrey Semashev wrote:

> Even nop requires decoding effort, so it does have a cost.

As I said before, on a recent out of order CPU it usually has no
statistically significant cost.

> And I was referring
> to ThreadSanitizer markup. Does it use the same markup as valgrind does?

Firstly, the only valid reason to use AddressSanitiser over valgrind
memcheck is when valgrind is too slow. The problem with
AddressSanitiser, like some other clang/GCC sanitisers, is that
*everything* in the process space needs to be compiled with the
sanitiser turned on. Otherwise memory corruption caused by an
uninstrumented bit of code can magically appear in other places, and
forget about debugging the cause easily. I personally use those
sanitisers which require everything to be compiled with them as a
quick smoke check, but use valgrind for finding causes.

The ThreadSanitiser doesn't need everything to be instrumented, and
it has the huge advantage of speed and memory consumption over
valgrind's helgrind or DRD. ThreadSanitiser has two versions, one
based on valgrind where a subset of DRD/helgrind instrumentation is
recognised, the other based on a clang backend which currently does
not recognise DRD/helgrind instrumentation.

The DRD/helgrind markup is really about *documentation* of use of
non-standard threading constructs, plus you can subvert the macros to
do other useful things e.g. auto-generate a ThreadSanitiser
suppressions file for you. The clang/GCC ThreadSanitizer is still in
beta, and reusing DRD/helgrind markup is a very likely feature add in
the future.

Hope this explains everything.


Currently unemployed and looking for work in Ireland.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at