Re: [boost] [thread] Address sanitizer failures on marshall-mac

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.

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/