|
From: Julian S. <js...@ac...> - 2006-01-21 02:58:01
|
Ashley
> #define V_START_GET(TARGET,LEN) \
> do { \
> VALGRIND_CHECK_WRITABLE(TARGET,LEN); \
> VALGRIND_MAKE_WRITABLE(TARGET,LEN); \
> } while (0)
>
> #define V_END_GET(TARGET,LEN) \
> do { \
> VALGRIND_MAKE_READABLE(TARGET,LEN); \
> } while (0)
>
> #define V_START_PUT(TARGET,LEN) \
> do { \
> VALGRIND_CHECK_READABLE(TARGET,LEN); \
> } while (0)
>
> Now my questions are mainly about the asynchronous get, it checks that
> the buffer it's been given is valid (VALGRIND_CHECK_WRITABLE) and
> temporarily marks it as addressable but undefined whilst the data is
> arriving. My question is what does VALGRIND_MAKE_WRITABLE do if the
> buffer isn't addressable before it's called. I don't want it to mark a
> buffer as addressable when it isn't, only to mark it as undefined while
> the network transfer is underway. Am I doing the right thing here?
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?
> Another request I have is can error reports from client requests include
> a byte counter in the output, in the case of buffer over-runs it would
> really help, in this case it was reading eight bytes from a malloced
> buffer of four although it's impossible to see that from the output.
>
> ==26004== Uninitialised byte(s) found during client check request
> ==26004== at 0x40641F3: elan_hbcast (common/group_hbcast.c:820)
> ==26004== by 0x8048661: main
> (in /opt/ashley/auto-build/quadrics/qstests/a.out)
> ==26004== Address 0x5ABDFC0 is 0 bytes inside a block of size 4 alloc'd
> ==26004== at 0x400446D: malloc (vg_replace_malloc.c:149)
> ==26004== by 0x804863E: main
> (in /opt/ashley/auto-build/quadrics/qstests/a.out)
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.
J
|