Re: two failures on libidn-1.22 testsuite (was: libidn-1.21 failed test tst_idna2)

[Guido Trentalancia]

Hi Simon !

Just a quick note to let you know that now with the latest version 1.22,
I get two failures with any optimisation flag greater than -O1 on gcc
(instead of just tst_idna2):

PASS: tst_stringprep
PASS: tst_punycode
PASS: tst_idna
==15596== Invalid read of size 4
==15596==    at 0x402E47: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x4030C4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400D95: doit (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400B8C: main (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==  Address 0x51ca8d8 is 8 bytes inside a block of size 10
alloc'd
==15596==    at 0x4C282CD: malloc (vg_replace_malloc.c:236)
==15596==    by 0x402F90: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x4030C4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400D95: doit (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400B8C: main (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596== 
==15596== Invalid read of size 4
==15596==    at 0x402E32: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x4030C4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400D95: doit (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400B8C: main (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==  Address 0x51d8ae0 is 0 bytes inside a block of size 3 alloc'd
==15596==    at 0x4C282CD: malloc (vg_replace_malloc.c:236)
==15596==    by 0x402F90: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x4030C4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400D95: doit (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596==    by 0x400B8C: main (in /usr/src/libidn-1.22/tests/tst_idna2)
==15596== 
FAIL: tst_idna2
PASS: tst_idna3
==15604== Invalid read of size 4
==15604==    at 0x401822: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x401AB4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x400CF1: doit (in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x400B3C: main (in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==  Address 0x51ca2d4 is 4 bytes inside a block of size 7 alloc'd
==15604==    at 0x4C282CD: malloc (vg_replace_malloc.c:236)
==15604==    by 0x401980: idna_to_ascii_4z
(in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x401AB4: idna_to_ascii_8z
(in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x400CF1: doit (in /usr/src/libidn-1.22/tests/tst_idna4)
==15604==    by 0x400B3C: main (in /usr/src/libidn-1.22/tests/tst_idna4)
==15604== 
FAIL: tst_idna4
PASS: tst_nfkc
PASS: tst_pr29
PASS: tst_strerror
PASS: tst_toutf8
PASS: tst_symbols
PASS: tst_tld
===================================
2 of 12 tests failed
Please report to address@hidden
===================================

With -O1 there are no failures.

However, if the problem lies in the library code rather than in the code
of the test (which we could call a false-alarm), then what would be the
outcome of a library produced with -O2 or -O3 ? I suppose that would be
a buggy library by all means, at least on that specific piece of code...

Please note that at the moment I have no time to follow up any better
than this. So I don't know the details, but at a first sight, my opinion
is still that such piece of code should be forcedly compiled with -O1 if
gcc is being used (which can be checked very easily and -O1 will always
override any other faster optimisation).

Regards,

Guido

On Mon, 2011-04-25 at 23:35 +0200, Simon Josefsson wrote:
> Guido Trentalancia <address@hidden> writes:
> 
> >> > Since we are not testing the compiler here, could we not avoid the
> >> > optimisation even when the user has explictly requested it ?
> >> 
> >> Valgrind will always test the compiler, since valgrind is checking the
> >> binary code.  I'm not sure what you mean by the second part -- having
> >> the code try to out-smart the person building the code rarely works
> >> well.  Since this was strlen, I suspect that you will get the same
> >> Valgrind error from almost any code.
> >> 
> >> > Using strnlen for example would lead to the same optimisation ?
> >> 
> >> Maybe, but it would be wrong to use strnlen here since the string is
> >> guaranteed to be zero terminated.
> >
> > Overriding inherited CFLAGS with -O1 in tests/Makefile (eventually just
> > for Valgrind tests) ?
> 
> First, the code that triggers Valgrind is in the library, not in the
> self test.  Also, -O1 is not a generic compiler flag, it is specific to
> gcc-like compilers and libidn works with other C compilers.  Finally,
> there is simply no way of knowing what flags "inverts" flags passed by
> the user in general.  If another user passes CFLAGS=--foo when building
> Libidn, we may need to provide --bar when building libidn to "invert"
> the effects of what the user requested.  Building with "-O1 --bar" just
> to deal with situation like yours does not lead to a robust project.
> 
> You are better off using the default build parameters unless you know
> what you are doing and are prepared to deal any issues.
> 
> /Simon
>