|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-09 22:25:08
|
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?=20 - Are those false positives? - Are those real problems but are the glibc maintainers not doing=20 anything about them? - Do these problems get reported to the glibc maintainers as they are found? Thanks, Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
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 |
|
From: Tom H. <to...@co...> - 2005-08-10 06:23:55
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> 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.
The main problem with the X libraries is that they send structure
across the network between client and server without initialising
any padding bytes isn't it?
Certainly uninitialised bytes in network writes is the common
complaint from the X libraries.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-10 10:13:21
|
> The main problem with the X libraries is that they send structure > across the network between client and server without initialising > any padding bytes isn't it? It's certainly _a_ common problem. But that would manifest itself as a passing-garbage-to-a-syscall style error, whereas IIRC almost all the default Xlib suppressions are common-or-garden uninitialised value use errors. Without someone auditing the X libraries we won't really know where the balance is. > Certainly uninitialised bytes in network writes is the common > complaint from the X libraries. Indeed. I believe that the KDE folks actually added code to zero out such buffers purely in order to make Valgrind be quiet(er) on KDE apps. J |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-11 19:51:39
|
On Wed, Aug 10, 2005 at 01:52:46AM +0100, Julian Seward wrote: > 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. I started looking at the patches and while reading the open3.patch I=20 wondered why that one would help. It fills in 0 for the optional third parameter to open calls. Both man=20 and info tell me the third parameter is only used when a file is being=20 created. Of the 50 or so changes, only 2 of them use O_CREAT. Is the problem here that it results in a syscall and a suppression=20 cannot work selectively based on the value of other parameters? Then I looked at the uninit patch, but I quickly got lost in the glibc source code.=20 What I still don't understand though is that these patches should help in getting rid of genuine problems reported by valgrind, while the reason for rejecting (some of) the patches is that nothing is done at run-time that is not absolutely necessary. It seems to me like both=20 parties are giving valid reasons for doing or not doing something, but they're not talking about the same thing. Either it's a genuine problem, valgrind should report it and glibc should spare no cycles to avoid it or it is not, valgrind should be quiet and glibc doesn't need to change. Regards, Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Nicholas N. <nj...@cs...> - 2005-08-11 20:18:48
|
On Thu, 11 Aug 2005, Maurice van der Pot wrote:
> It fills in 0 for the optional third parameter to open calls. Both man
> and info tell me the third parameter is only used when a file is being
> created. Of the 50 or so changes, only 2 of them use O_CREAT.
I haven't looked at the code, but Valgrind should be able to handle this.
Here's the relevant code in the wrapper for open():
PRE(sys_open)
{
*flags |= SfMayBlock;
if (ARG2 & VKI_O_CREAT) {
// 3-arg version
PRINT("sys_open ( %p(%s), %d, %d )",ARG1,ARG1,ARG2,ARG3);
PRE_REG_READ3(long, "open",
const char *, filename, int, flags, int, mode);
} else {
// 2-arg version
PRINT("sys_open ( %p(%s), %d )",ARG1,ARG1,ARG2);
PRE_REG_READ2(long, "open",
const char *, filename, int, flags);
}
PRE_MEM_RASCIIZ( "open(filename)", ARG1 );
}
N
|