Bug#626389: libc6: uninitialised value via gconv_open.c:70

[Aurelien Jarno <aurelien@aurel32.net>]

reassign 626389 valgrind
thanks

On Wed, May 11, 2011 at 03:51:10PM +0200, Julian Andres Klode wrote:
> Package: libc6, valgrind
> Version: libc6/2.13-2
> Severity: normal
> 
> It seems that with the new libc6 package, we get some more uninitialized
> values. There seems to be a value uninitialized somewhere (something
> pointed to by _nl_C_locobj_ptr?), causing dgettext() to produce warnings
> in valgrind, as seen in the example.

The problem is on the valgrind side. The new version of strcasecmp uses
sse to compare strings, and compare them 16 bytes by 16 bytes:

        pxor    %xmm0, %xmm0            /* clear %xmm0 for null char checks */
        pcmpeqb %xmm1, %xmm0            /* Any null chars? */
        pcmpeqb %xmm2, %xmm1            /* compare first 16 bytes for equality */
        psubb   %xmm0, %xmm1            /* packed sub of comparison results*/
        pmovmskb %xmm1, %edx
        sub     $0xffff, %edx           /* if first 16 bytes are same, edx == 0xffff */
        jnz     LABEL(less16bytes)      /* If not, find different value or null char */

In your case, at least one of the string is shorter than 15 character,
which means it contains a null byte in the first 16 bytes. It is caught
by the first pcmpeqb and the jump will always be taken. It means that 
even if some uninitialized data (the bytes after the null byte) is 
fed to some of the instructions, the jump actually never depends on 
uninitialized data.

valgrind just misses the fact that the data is a string, and that it is
ended by a null byte. This is definitely a valgrind bug, not a libc one.

The same kind of reasoning applies to the too other cases.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net