|
From: Julian S. <js...@ac...> - 2005-08-10 00:47:08
|
On Tuesday 09 August 2005 21:17, Maurice van der Pot wrote: > I have a couple of questions that are probably beginner's questions, > but I never got around to asking them. > > - What is the reason that valgrind has default suppression files for > glibc? > - Are those false positives? > - Are those real problems but are the glibc maintainers not doing > anything about them? > - Do these problems get reported to the glibc maintainers as they are > found? No, these are good questions, and they point at a problem. Maybe you know how to solve it. I was thinking about this the other day. ------ The original motivation for the suppression files was that Memcheck was more or less unusable without them, because it reported a lot of errors in glibc. Many of these are to do with the ultra-optimised strlen etc functions, and so are false positives, but we deal with them better these days. Some are probably real errors. But this leads to a circular problem. Valgrind suppresses glibc errors so you don't get swamped by them, but in doing so more or less means they never come to the attention of the glibc authors and presumably never get fixed. John Reiser has an audited (cleaned-up) version of glibc-2.3.5; the comments at http://bitwagon.com/glibc-audit/glibc-audit.html make interesting reading. I think it's a great shame that the glibc folks don't make glibc Valgrind-clean given the almost unmeasurably small performance overhead John says this would have (and I believe it); this seems to me a poor tradeoff. The circularity problem is, however, much worse for the X client libraries. Valgrind's default .supp files contain literally dozens of suppressions for errors reported in the X libraries. I'm not saying Xlib et al are particularly buggy. But it would be nice if we didn't have to suppress this much. I'd be happy to offer guidance, assistance, etc, to any X.org developers who wanted to look Valgrinding X.org; then at least we would know whether these are real bugs or false errors. ------ So .. why was I thinking about this recently? Because recently I have been trying to make Memcheck work well on (32-bit) PowerPC Linux (the 3.0.0 line has lots of ppc-linux infrastructure in place). But without much success -- I got flooded with uninitialised value errors which I cannot track down. So right now, I don't know if they are false reports caused by endianness bugs in Memcheck, or if they are real bugs in glibc on ppc32-linux. If I knew glibc was valgrind- clean this it would be a lot less confusing. J |