Subject: Re: [boost] A summary of testing with sanitizers
From: Ben Pope (benpope81_at_[hidden])
Date: 2015-05-12 09:02:42
On Friday, May 08, 2015 12:40 AM, John Maddock wrote:
> On 07/05/2015 16:52, Ben Pope wrote:
>> On Thursday, May 07, 2015 11:33 PM, John Maddock wrote:
>>>> 15 SUMMARY: MemorySanitizer: use-of-uninitialized-value
>>> After banging my head against the wall that is memory-sanitizer for a
>>> while, I finally figured out that the multiprecision failures are caused
>>> by external libraries (gmp, mpfr etc) not being built with sanitizer
>>> support. I've changed the configuration tests to trigger
>>> memory-sanitizer errors when this is the case, so that these will no
>>> longer be built in that case. However, you will need to manually delete
>>> the Boost.Build configuration caches (or all of bin.v2) in order for the
>>> fix to take effect, as these appear not to be subject to
>>> dependency-checking :(
>> What if I build sanitised versions? How many dependant libraries
>> would need to be built?
> The code is such that if the config tests are linked against sanitized
> libraries they will pass and the tests will be built as normal - which
> might well be useful actually - though I confess I've found clang's
> memory sanitizer to be a right pain to use with utterly inscrutable
> error messages. Just my 2c... though I guess it is marked as "not
> ready for widespead use".
> The libraries effected are gmp, mpfr, mpfi and tommath (the latter two
> are probably not installed by default anyway).
OK, hopefully I'll get a chance to look at this some time. Looks like
msan is segfaulting most of the time anyway, perhaps because I added
LLVMs libunwind. On the plus side, looks like ubsan is fixed.
> BTW there are also a lot of multiprecision tests failing because of the
> 300 second timeout - seems to be the -fsanitize=memory and
> -fsanitize=undefined that are causing the issues - do these
> significantly slow compile times?
I don't think compilation time is significantly affected, but runtime
and memory usage can be, at least for msan. With -j7, I wouldn't be
surprised if it blows way past my 16GB RAM and into 32GB land or more.
Also, I've forced -O1 for more useful stack traces, so if you depend on
aggressive optimisations for performance, that might explain it.
I'm running it again with a larger timeout. Scrap that, no I'm not,
because I messed it up.
Next time I'll run it with a larger timeout.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk