Bug#751680: [libc6] valgrind based testsuites fail because of new lib6
reassign 751680 valgrind
retitle 751680 please update valgrind suppression file for glibc 2.19
thanks
On Sun, Jun 15, 2014 at 03:43:51PM +0100, Franz Schrober wrote:
> Package: libc6
> Version: 2.19-1
> Severity: normal
> Everytime I start a testsuite with valgrind (like the git testsuite) it now fails with a backtrace like this:
>
> ==6881== Conditional jump or move depends on uninitialised value(s)
> ==6881== at 0x40177C1: index (strchr.S:40)
> ==6881== by 0x400740D: expand_dynamic_string_token (dl-load.c:425)
> ==6881== by 0x400759B: fillin_rpath (dl-load.c:495)
> ==6881== by 0x4007D29: _dl_init_paths (dl-load.c:872)
> ==6881== by 0x4002BC9: dl_main (rtld.c:1349)
> ==6881== by 0x4015334: _dl_sysdep_start (dl-sysdep.c:249)
> ==6881== by 0x4004A35: _dl_start (rtld.c:332)
> ==6881== by 0x4001197: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
> ==6881== Uninitialised value was created by a stack allocation
> ==6881== at 0x4007C91: _dl_init_paths (dl-load.c:840)
> ==6881==
> ==6881== Conditional jump or move depends on uninitialised value(s)
> ==6881== at 0x4017834: index (strchr.S:77)
> ==6881== by 0x400740D: expand_dynamic_string_token (dl-load.c:425)
> ==6881== by 0x400803D: _dl_map_object (dl-load.c:2538)
> ==6881== by 0x400137D: map_doit (rtld.c:627)
> ==6881== by 0x400E8E3: _dl_catch_error (dl-error.c:187)
> ==6881== by 0x4000B2E: do_preload (rtld.c:816)
> ==6881== by 0x4004147: dl_main (rtld.c:1635)
> ==6881== by 0x4015334: _dl_sysdep_start (dl-sysdep.c:249)
> ==6881== by 0x4004A35: _dl_start (rtld.c:332)
> ==6881== by 0x4001197: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
> ==6881== Uninitialised value was created by a stack allocation
> ==6881== at 0x40040D3: dl_main (rtld.c:1625)
> ==6881==
>
> This didn't happen with the old libc6 version
These are false positives from valgrind, as the optimized assembly code
is reading more data than the string length for performance reasons.
I am reassigning the bug to valgrind, an update of the suppression files
should be done there.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: