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 09:25:45

On 8 Mar 2014 at 0:55, Andrey Semashev wrote:

> > The main cause of false positives is when Boost uses atomics to
> > implement low level primitives such as locks. You need to annotate
> > all CAS lock operations with the fact they are CAS locks - that way a
> > thread sanitiser knows you're serialising code. Otherwise it appears
> > you're riddling your code with race conditions.
> 
> I think you're confusing ThreadSanitizer and AddressSanitizer. Double
> free is never a false positive.

No, but I think you didn't understand my post. Double frees which 
apparently occur Boost.Thread may in fact be double deletes in 
upstream code, so if type Foo's destructor has at some point the 
destruction of say a boost::future<>, double deleting Foo will appear 
as if Boost.Thread is double freeing. In fact the fault is in 
upstream code, not Boost.Thread.

> > Marking up all of Boost.Thread with all the necessary annotations and
> > fixing up any problems revealed is probably a full (and extremely
> > worthwhile) GSoC.
> 
> I'd be careful with such markup. I don't know how exactly
> ThreadSanitizer works, but if markup means calling some function in
> runtime then that's probably not an acceptable solution in the context
> of atomics.

No functions are called in valgrind inserted markup. Just some 
harmless bytes which act as fingerprints. Normally the CPU skips 
right over them.

Many codebases ship valgrind fingerprints in final release build 
images (AFIO is one of them). I found no statistically significant 
difference in performance nor bloat on out of order CPUs. In short: 
valgrind is very well designed, unsurprising as it came from the mind 
of Julian Seward.

Niall

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