Broad valgrind run

[bodrato at mail.dm.unipi.it]

Ciao,

Il Mer, 5 Novembre 2014 11:36 pm, Torbjörn Granlund ha scritto:
> tg at gmplib.org (Torbjörn Granlund) writes:
>   I decided to test running the nightly GMP runs under valgrind.  We've

> Time for some conclusions.

To be honest, our test-suite is not Valgrind-ready, but the opposite...

Many loops under the tests/ directory use "red-zones", i.e. allocate one
more limb before and one more limb after the needed memory area to detect
changes. This way Valgrind will not be triggered by wrong reads just
outside the correct buffer. Possibly wrong "buf[-1]--; buf[-1]++;" will
get unnoticed by both Valgrind (because the limb is allocated) and the
red-zone mechanism (because the final value is unchanged).

Maybe we should add an --enable-valgrind-memcheck option to configure,
then use the "Client Requests" to refine red-zoning.

I just added a couple of ASSERTs to toom22 code and realised that the
usable range is slightly smaller than I expected. Not a problem, because
those corner cases are never used inside the library.
I mention this issue here, because it could be detected using Valgrind on
a patched test-suite. I attach the dumb patch I tested, with it Valgrind
detects the problem:

$ valgrind tests/mpn/t-toom22
==4566== Memcheck, a memory error detector
==4566== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4566== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==4566== Command: tests/mpn/t-toom22
==4566==
==4566== Invalid read of size 8
==4566==    at 0x40EF20: __gmpn_toom22_mul (in ...)
==4566==    by 0x401311: main (in ...)
==4566==  Address 0xffeff3d08 is 96 bytes inside a after result pp of size
16,392 client-defined
==4566==    at 0x400E1A: main (in ...

-- 
http://bodrato.it/papers/




-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind-toom-tests.diff
Type: text/x-patch
Size: 2384 bytes
Desc: not available
URL: <https://gmplib.org/list-archives/gmp-devel/attachments/20150606/2aba9e17/attachment.bin>