valgrind stuff

Brandon Black blblack at
Thu Apr 10 01:56:22 CEST 2008

Marc Lehmann wrote:
> On Wed, Apr 09, 2008 at 06:15:27PM -0500, Brandon Black <blblack at> wrote:
>> Regardless, if poll() returns zero there's no point in examining revents 
>> anyways right?
> The extra test might slow you down when you need it most, when you are in
> a tight loop handling I/O events, especially when it is hard to predict.
>> That makes the whole issue moot. 
> Well, I'd rather have bugs fixed, especially in tools like valgrind that I
> use myself.
> You might not care about the quality of the software you use, but I do. And
> when I use valgrind, I expect useful and good results, not false positives.
> Think about how much time you and I already have potentially wasted on this
> valgrund bug. This wouldn't have been neccessary if valgrind were fixed.
> And yes, you might not care, but I am happy when _other_ people who find
> out about these issues get the real bug fixed, so _I_ do not have to waste
> time investigating them. With your attitude, everybody would just slap
> workarounds around kernel bugs and everybody would have to reinvent those
> workarounds again and again.
> I have different standards.

No need to get personal with attacks on my "standards".  If it's a 
valgrind bug then fine, it's a valgrind bug.

>> If anything you gain some performance by not scanning the poll_fd's in
>> the case of a timeout with no events occuring.
> Micro-optimisations like these often don't have the intended effect,
> though, you have to look at the larger picture.
> Besides, the point is not avoiding code changes to libev - if you had
> looked, you had seen that I already added a workaround, despite having no
> indicationg of this beign a real problem.
> The point is a) fixing a real bug in a tool people rely on (valgrind) and
> b) helping others by epxloring and fixing the issue, instead of blindly
> applying some kludgy that might not even be necessary and letting others
> stumble upon the same problems.

Look, either the change you applied to skip scanning revents on a retval 
of zero is a "blind kludge" or an optimization that happens to 
workaround a valgrind bug.  If you think it's a blind kludge and its 
optimization value is dubious (or even negative), then by all means 
don't apply the workaround, nobody's forcing you.

> And yes, you might not care, but that doesn't mean it's good if other
> people care for the quality of their and other's software. Free software
> lives from people who *do* care about bugs, otherwise free software
> wouldn't have the high quality that is (usually) has.

All I've done here is seen a valgrind output flagging a potential 
problem and tried my best to follow up on what it means.  I don't see 
how that is any indication that I lack standards.

-- Brandon

More information about the libev mailing list