Re: [boost] A summary of testing with sanitizers

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
>>>> /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10
>>>>
>>>> in
>>>> boost::multiprecision::backends::detail::gmp_float_imp<50u>::~gmp_float_imp()
>>>>
>>>>
>>>
>>> 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.

Ben