The patch is against the cvs version of app-portage/portage-utils because the last version in portage got even more valgrind errors than the CVS one. Reproducible: Always Steps to Reproduce: 1. Install the memory debugger valgrind. 2. Check out and built portage-utils from cvs 3. Run valgrind ./q Actual Results: ==29978== Memcheck, a memory error detector. ==29978== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==29978== Using LibVEX rev 1804, a library for dynamic binary translation. ==29978== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==29978== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==29978== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==29978== For more details, rerun with: -v ==29978== ==29978== Conditional jump or move depends on uninitialised value(s) ==29978== at 0x40C046: initialize_portage_env (main.c:487) ==29978== by 0x40C53F: main (main.c:1036) ==29978== ==29978== Conditional jump or move depends on uninitialised value(s) ==29978== at 0x4A08620: memmove (mc_replace_strmem.c:516) ==29978== by 0x40C081: initialize_portage_env (main.c:487) ==29978== by 0x40C53F: main (main.c:1036) ==29978== ==29978== Use of uninitialised value of size 8 ==29978== at 0x4A08630: memmove (mc_replace_strmem.c:516) ==29978== by 0x40C081: initialize_portage_env (main.c:487) ==29978== by 0x40C53F: main (main.c:1036) ==29978== ==29978== Use of uninitialised value of size 8 ==29978== at 0x4A08639: memmove (mc_replace_strmem.c:516) ==29978== by 0x40C081: initialize_portage_env (main.c:487) ==29978== by 0x40C53F: main (main.c:1036) ==29978== ==29978== Conditional jump or move depends on uninitialised value(s) ==29978== at 0x4A08641: memmove (mc_replace_strmem.c:516) ==29978== by 0x40C081: initialize_portage_env (main.c:487) ==29978== by 0x40C53F: main (main.c:1036) ==29978== ==29978== Conditional jump or move depends on uninitialised value(s) ==29978== at 0x4A08307: strlen (mc_replace_strmem.c:242) ==29978== by 0x3AA74446F3: vfprintf (in /lib64/libc-2.6.1.so) ==29978== by 0x3AA74667B9: vsnprintf (in /lib64/libc-2.6.1.so) ==29978== by 0x3AA744A4C2: snprintf (in /lib64/libc-2.6.1.so) ==29978== by 0x40C3F4: initialize_portage_env (main.c:492) ==29978== by 0x40C53F: main (main.c:1036) Usage: q <applet> <args> : invoke a portage utility applet Currently defined applets: q <applet> <args> : virtual applet qatom <pkg> : split atom strings qcache <action> <args> : search the metadata cache qcheck <pkgname> : verify integrity of installed packages qdepends <pkgname> : show dependency info qfile <filename> : list all pkgs owning files qglsa <action> <list> : check GLSAs against system qgrep <misc args> : grep in ebuilds qlist <pkgname> : list files owned by pkgname qlop <pkgname> : emerge log analyzer qmerge <pkgnames> : fetch and merge binary package qpkg <misc args> : manipulate Gentoo binpkgs qsearch <regex> : search pkgname/desc qsize <pkgname> : calculate size usage qtbz2 <misc args> : manipulate tbz2 packages quse <useflag> : find pkgs using useflags qxpak <misc args> : manipulate xpak archives Options: -[irmM:vqChV] -i, --install * Install symlinks for applets -r, --reinitialize * Reinitialize ebuild cache -m, --metacache * Reinitialize metadata cache -M, --modpath <arg> * Module path -v, --verbose * Make a lot of noise -q, --quiet * Tighter output; suppress warnings -C, --nocolor * Don't output color -h, --help * Print this help and exit -V, --version * Print version and exit ==29978== ==29978== ERROR SUMMARY: 64 errors from 6 contexts (suppressed: 5 from 1) ==29978== malloc/free: in use at exit: 0 bytes in 0 blocks. ==29978== malloc/free: 16 allocs, 16 frees, 7,209 bytes allocated. ==29978== For counts of detected errors, rerun with: -v ==29978== All heap blocks were freed -- no leaks are possible. Expected Results: A message like: ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) A patch will be attached shortly. The issue that the patch solves is that readlink does not add a ending null byte to the buffer, nor is the buffer previously initialized. strlen is then used on the buffer, but strlen only stops when it hits a \0. Thus the code needs to check the return value of readlink and add a \0 as needed. It is not really possible to just use strnlen and such due to that the string is used in snprintf a bit below. For the same reason the memmove used to move the string (in order to make place for a /etc/ in front) also have to be adjusted to copy the previously added null byte. This bug is minor because the code happened to work before, due to pure luck (nothing larger had been allocated before on the stack, and therefore the buffer happened to contain a lot of null bytes, but depending on that is not the right way to do it).
Created attachment 152833 [details, diff] fix-uninitialised-value.patch The patch to fix the issue.
This patch will be in the next release.
