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 [email protected] =================================== 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 <[email protected]> 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 > _______________________________________________ Help-libidn mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-libidn
