[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libidn-1.21 failed test tst_idna2
From: |
Simon Josefsson |
Subject: |
Re: libidn-1.21 failed test tst_idna2 |
Date: |
Mon, 25 Apr 2011 22:03:22 +0200 |
User-agent: |
Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) |
Guido Trentalancia <address@hidden> writes:
> Hi Simon !
>
> Thanks for your feedback.
>
> On Mon, 2011-04-25 at 21:20 +0200, Simon Josefsson wrote:
>> Guido Trentalancia <address@hidden> writes:
>>
>> > Hello Simon !
>>
>> Hi! I re-added help-libidn on the cc list, please keep it so that
>> others can learn from our discussion.
>>
>> > Here is the output with -g added:
>> ..
>> > ==31295== Invalid read of size 4
>> > ==31295== at 0x402E46: idna_to_ascii_4z (idna.c:516)
>> ...
>> > ==31295== Address 0x51ca8d8 is 8 bytes inside a block of size 10
>> > alloc'd
>> > ==31295== at 0x4C282CD: malloc (vg_replace_malloc.c:236)
>> > ==31295== by 0x402F90: idna_to_ascii_4z (idna.c:528)
>> ...
>> > Using only -g in the CFLAGS and dropping all the rest (-O3 and
>> > processor-specific optimisations) produces no errors.
>> >
>> > The problem is triggered by -O3, -O2 but not -O1.
>>
>> That offending line contains a strlen. I think this is just a matter of
>> the compiler chosing a (too) optimized 'strlen' implementation that
>> reads in chunks of 4 bytes even when the buffer is shorter. In this
>> case, it reads 4 + 4 + 4 bytes but the buffer is only 10 bytes
>
> 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.
>> It could be a compiler bug, but I suspect it is intentional to read even
>> beyond the end of a buffer because it will be faster. Thus, unless it
>> is a compiler bug, you need to compile with the default compiler flags
>> or specify --disable-valgrind-tests when building libidn.
>
> At least you could add a note...?
I have explained the parameter in the manual now:
http://git.savannah.gnu.org/cgit/libidn.git/commit/?id=fed6dbd707975dbcc9e7e7817a377f058eef181d
/Simon