https://bugs.kde.org/show_bug.cgi?id=473745
--- Comment #6 from Mark Wielaard <m...@klomp.org> --- (In reply to Paul Floyd from comment #2) > The only thing that I can think of that could affect that is the delayed > loading of debuginfo. That might be it. If I remember correctly Debian/Ubuntu doesn't keep symtab in glibc, so always need the glibc dbg package to be installed. If so, this might also be resolved if you follow the packaging recommendation for ld.so from README_PACKAGERS. -- Do not ship your Linux distro with a completely stripped /lib/ld.so. At least leave the debugging symbol names on -- line number info isn't necessary. If you don't want to leave symbols on ld.so, alternatively you can have your distro install ld.so's debuginfo package by default, or make ld.so.debuginfo be a requirement of your Valgrind RPM/DEB/whatever. Reason for this is that Valgrind's Memcheck tool needs to intercept calls to, and provide replacements for, some symbols in ld.so at startup (most importantly strlen). If it cannot do that, Memcheck shows a large number of false positives due to the highly optimised strlen (etc) routines in ld.so. This has caused some trouble in the past. As of version 3.3.0, on some targets (ppc32-linux, ppc64-linux), Memcheck will simply stop at startup (and print an error message) if such symbols are not present, because it is infeasible to continue. It's not like this is going to cost you much space. We only need the symbols for ld.so (a few K at most). Not the debug info and not any debuginfo or extra symbols for any other libraries. -- You are receiving this mail because: You are watching all bug changes.
