|
From: Nicholas N. <nj...@ca...> - 2004-08-10 12:57:57
|
Hi, I've got the basics working for Memcheck to check whether syscall args are uninitialised. This strikes me as a good thing. Here's an example error: ==26325== Syscall param write(fd) contains uninitialised or unaddressable byte(s) ==26325== at 0x420D2473: write (in /lib/tls/libc-2.3.2.so) ==26325== by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) ==26325== by 0x8048298: ??? (start.S:81) ==26325== Address 0xFFFFFFFF is not stack'd, malloc'd or (recently) free'd I've piggybacked it onto the "Param" error kind, which explains the strange address. I think I will change Memcheck so that if the address passed into a Param error is (void*)-1, then it won't display the address part of the error. (I could also change the error message to omit the "or unaddressable" part in this case.) ---- I also propose to slightly change the current Param error output so as to distinguish between errors in the syscall arguments, and errors in the memory pointed to by syscall arguments. Eg, where we currently say: Syscall param write(buf) contains uninitialised... to mean that the memory pointed to by buf is bad, I would change this to mean that buf itself is bad. I would use Syscall param write(*buf) contains uninitialised... to indicate that the memory pointed to by buf is bad. (Nb: if buf is bad, there's a good chance that *buf is also bad.) The downside of this is that it would break some existing Param suppressions, and possibly affect tools post-processing Valgrind's output. I guess I could use something like "write(&buf)" for the new errors, but that's confusing. Maybe this non-compatibility is not a big problem? Does anyone else have any other ideas? ---- Adding in all the syscall arg names will be tedious... is there anywhere in the Linux source code where these are shown? AFAICT, that information is completely spread throughout the source tree. If not, I guess I'll be trawling through man pages, hoping that the glibc arg names match up with the kernel ones... ---- Similarly, I plan to check client request args. I'm not yet sure if I'll piggyback those errors onto the Param error kind, or create a new one. The new one would be extremely similar, though. N |