* Justin Pryzby:
JP> valgrind reports 13 instances of "Conditional jump or move depends
JP> on uninitialised value(s)" using the new libc6 in testing, for a
JP> trivial program which just calls exit(0). This is
JP> valgrind-2.4.0-3.
FW> This means that the valgrind suppression files are out of date.
FW> Unless you've actual evidence that these are bugs, this should be
FW> fixed in valgrind.
This is still happening with the Debian-packaged version 3.0.1-1 and
the latest development version, and I think I can explain why, though
it seems hard to fix from the Valgrind side.
Valgrind's suppressions are up to date, the problem is that they
aren't effective because /lib/ld-linux.so.2 has less symbol
information than it used to.
For a while now, Debian has been shipping a /lib/ld-linux.so.2 library
that's stripped, i.e., has no static symbols. I believe this is the
standard Debian policy for shared libraries, though it's somewhat
unusual compared to other distributions. The dynamic linker does still
have a few dynamic symbols, though, mainly related to its rather
intimate relations with libc.so. In the older (2.3.2, sarge-era)
versions of libc, the list of dynamic symbols happened to include the
function where an error was occurring (_dl_relocate_object); since
Valgrind can read dynamic symbols, it was able to see the function
name and the suppression worked.
In newer glibc versions (I'm testing with 2.3.5-6), the number of
dynamic symbols exported from ld-linux.so.2 has been reduced, excluding
in particular the functions that Valgrind needs to match the
suppressions for the various sloppy memory uses in this version.
I believe the missing symbols affect more than the cosmetic issue of
suppressions: Valgrind also needs to redirect functions from the
dynamic linker, and it can't do that if it doesn't know where they
are. I think this leads to segfaults for larger programs.
One potential workaround is to use the debugging version of
ld-linux.so.2 from libc6-dbg, which us unstripped; I've appended a
patch to make that change to the end of this message. However, the
upstream developers weren't too crazy about this idea, and adding a
dependency on libc6-dbg would have priority issues, if I understand
correctly.
Another possibility would be to try to convince the libc6 package
maintainers not to strip /lib/ld-linux.so.2; I'm not sure how willing
they'd be to do that.
-- Stephen
Index: coregrind/m_ume.c
===================================================================
--- coregrind/m_ume.c (revision 4894)
+++ coregrind/m_ume.c (working copy)
@@ -530,19 +530,26 @@
case PT_INTERP: {
char *buf = VG_(malloc)(ph->p_filesz+1);
int j;
- int intfd;
+ int intfd = -1;
int baseaddr_set;
vg_assert(buf);
VG_(pread)(fd, buf, ph->p_filesz, ph->p_offset);
buf[ph->p_filesz] = '\0';
- sres = VG_(open)(buf, VKI_O_RDONLY, 0);
- if (sres.isError) {
- VG_(printf)("valgrind: m_ume.c: can't open interpreter\n");
- VG_(exit)(1);
+ if (!VG_(strcmp)(buf, "/lib/ld-linux.so.2")) {
+ sres = VG_(open)("/usr/lib/debug/ld-linux.so.2", VKI_O_RDONLY, 0);
+ if (!sres.isError)
+ intfd = sres.val;
}
- intfd = sres.val;
+ if (intfd == -1) {
+ sres = VG_(open)(buf, VKI_O_RDONLY, 0);
+ if (sres.isError) {
+ VG_(printf)("valgrind: m_ume.c: can't open interpreter\n");
+ VG_(exit)(1);
+ }
+ intfd = sres.val;
+ }
interp = readelf(intfd, buf);
if (interp == NULL) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
