Boost logo

Boost :

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.


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

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