Re: [Valgrind-users] FD leakage

[John R. <jr...@Bi...>]

Tom Hughes wrote:
> In message <3FF...@Bi...>
>           John Reiser <jr...@Bi...> wrote:
> 
> 
>>so that legal but uncommon usage does not get a "false positive"
>>error report.  I also do not like "false negative" reports (undiagnosed
>>actual errors.)  I have been disappointed by Valgrind/memcheck
>>several times in these regards:
> 
> 
> Problems are more likely to fixed if you report them, and I don't
> recall seeing any mention of most of the things you refer to. 

The archives of Valgrind-users show these messages from me:
-----
04/29/2003 [Valgrind-users] checking the arguments to system calls?
        Mentions the scalar args to syscalls (such as 3rd argument to open()
        or missing trailing arguments to mmap()), and the byte arrays to
        select() being rounded differently.

11/20/2003 [Valgrind-users] memcheck 2.0.0 overlooks uninit bit [false negative error report]
        Memcheck gives carte blanche to a basic block that uses 0x80808080.

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.
-----
and there have been numerous messages from other users about specific
unimplemented opcodes.


> In fact now we have a bug tracker the best was to ensure they are known about
> is to raise a bug.
> 
> 
>>                                 scalar args to syscalls are not
>>checked for being defined,
> 
> 
> An interesting point, and one that had crossed my mind in the past. It
> ought to be doable but requires a bit of effort to work out the number
> of arguments for each call and deal with varargs syscalls.
> 
> 
>>                           memcheck rounds the byte array args to
>>select() _down_ to a multiple of 8 bits while the kernel rounds them
>>_up_ to a multiple of 32 bits,
> 
> 
> The kernel may round up and read whole words, but I bet it doesn't pay
> attention to the extra bits in the last word as that would appear to be
> wrong to me. 

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.
The kernel acts as the user's agent in touching memory, and the kernel takes
this responsibility very seriously.  Memcheck ought to be just as careful.
The same principle applies to scalar arguments to system calls.  The kernel
(acting as an agent of the user) makes decisions based on the values in
those registers, so memcheck should check the values for being [un]defined.

 > The interface that valgrind uses to check syscall args can
> currently only check to byte granularity, hence it rounds down to the
> nearest byte and ignores any odd bits. That is indeed a bug, but one that
> is slightly finicky to fix.
> 
> 
>>                               the appearance of the immediate constant
>>0x01010101 suppresses all errors even if the basic block is not doing
>>optimistic memory scanning [such as strlen(), etc.],
> 
> 
> I do remember that one being mentioned but I'm not aware that anybody
> has come up with a good alternative to the current behaviour.

Why not look at the code and figure out what it is doing?   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."

> 
> 
>>                                                     and the continuing
>>unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3).
> 
> 
> There is pretty good coverage of these now I think. We certainly don't
> seem to be seeing many reports of this now and the ones we do get are
> usually patched fairly quickly and short of a volunteer to go through
> the architecture reference manual and implement any missing instructions
> it isn't clear what more could be done.

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 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.

-- 
John Reiser, jr...@Bi...