Re: [Valgrind-users] FD leakage

[Sebastian K. <Seb...@so...>]

From: "John Reiser" <jr...@Bi...>
[snip]
> 11/20/2003 [Valgrind-users] memcheck 2.0.0 complains about init bit [false
positive error report]
>         Unsigned remainder has properties that memcheck does not
understand.

This one has been dismissed as splitting hairs. There are infinite number of
similar cases, and barrierr must be put somewhere.

[snip]
> The kernel certainly does pay attention to those extra bits in the
> last word.  In fact, the kernel pays attention so closely that it returns
> EFAULT if any of those extra bits do not exist, such as if they are in
> a non-mapped page.  For example, a user bug may position one of the arrays
for
> select() so that the byte that contains the bit for highest_fd is at the
high
> end of the highest page in a segment, but the byte that contains the bit
for
> (037 | highest_fd) is in the next higher page, and therefore is not
present.

This is some utterly rare case, as it requires the FD array to be misaligned
to begin with. And then if there is such bug kernel itself complains.
Besides: why not post patch instead of complaining?

> Why not look at the code and figure out what it is doing?

Who/What should look at the code and figure that? Memcheck?

> It might
> become confusing or the results might be inconclusive, but there is
> a large difference between "cannot understand this particular case"
> and "will not even try."

Memcheck is a piece of software, and runtime checks must be algorithmically
simple to allow reasonable speed. It doesn't understand anything, obviously
as it's not thinking to begin with.

> The first thing that could be done is count the number of architected
> opcodes (including prefixes) that remain unimplemented.  Put that number
> in the user-level documentation, put the specific list and classification
> of the missing cases and a suggested order of implementation in the
developer
> documentation, and _then_ ask for volunteers.  Advertising the specifics
> is much more likely to create interest than a vague "there are some
> unimplemented opcodes."

As you seem to be interested, why don't you try it yourself.

> > As with all free software, you get out what you put in.
>
> I put in test cases, I get out bugs -- enough to demonstrate that memcheck
> has a ways to go before I should rely on it to check non-test code.

So it will never be at the state *you* could rely on it. You seem to be
0,infinity guy -- i.e. the only values interesting to you are 0,and infinity
and rest you disregard as uninteresting and reduce to 0 or infinity. Valgrnd
can never be exact, as this is simply intractable problem (computationally
impossible at all, as is determing if particular Turing Machine will stop).
If you're waiting for universal bug killer then you can wait forever.

Is hunting significant number of bugs is for you the same as hunting
nothing? Reduction to 0?

rgds
Sebastina Kaliszewski