|
From: Ashley P. <as...@qu...> - 2006-01-23 13:48:36
|
On Sat, 2006-01-21 at 02:57 +0000, Julian Seward wrote: > My impression is that what you need to do is: > > - at the initial request (V_START_GET), first check the recv > buffer is addressible (VALGRIND_CHECK_WRITABLE), and then > force it to be unaddressible so V will yelp if anyone pokes > there (VALGRIND_MAKE_NOACCESS) > > - when the request completes and you know how much data really > arrived, do VALGRIND_MAKE_READABLE. This marks the area as > both addressible and containing defined data. > > Does that make sense? This sounds almost exactly what I want, I was thinking that the data should be addressable but undefined between the get() and the wait() however unaddressable would do. I'll try some experiments with it. > The problem here is there are two possible sources of error and V can > only report one or the other. Let . mean a byte which is unaddressible > and X mean one which is addressible but is undefined. Your buffer > looks like this > > .......XXXX...... > ^ > a > > Now you do VALGRIND_CHECK_READABLE(a,8). Should it complain that > a[0 .. 3] are undefined, or that a[4 .. 7] are unaddressible? Both > are legitimate complaints. I think the reason for the confusion is > that it's reporting the former and you're expecting the latter. > > If those four bytes were defined then it should indeed complain > about a[4..7] being unaddressible. > > Could be I'm way off base, but I _think_ that's the behaviour. I'm not to concerned about which is complains about in this case, in fact that side of it isn't something I'd considered, what I'd like it to say is something like the following: "...found during client check request of size 8" For memory reads/writes the size is implicit in the operation and reported as such but with client checks it's harder to tell currently. Ashley, |