|
From: Tristan V. B. <va...@to...> - 2003-07-16 18:21:39
|
Hi all,
I've been fooling around with valgrind (very impressed btw) and I'm not
100% clear on all the program output.
firstly, maybe there is an available FAQ for understanding vg output ?
I checked the usual culprits i.e. vg.sf.net && sf.net/projects/vg and
couldn't
find such a beast.
secondly, if anyone understands this better that I do that would be
great ;-)
this is what is presently baffeling me:
==1854== Syscall param socketcall.sendto(msg) contains uninitialised or
unaddressable byte(s)
==1854== at 0x408E2D92: __libc_sendto (in /lib/libc-2.1.3.so)
==1854== by 0x40815AA6: trans_send (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
==1854== by 0x40813D63: evts_send (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
==1854== by 0x40814A0F: sync_call (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
the "msg" param in my case is definitly initialized (even added memset
to be sure).
now what could be meant by "unaddressable bytes" ? could this be a
result of sending
a message of 63 bytes instead of 64 (meaning only one of every 4 bytes
is "truely addressable") ?
I'm not feeding `sendto' any register variables if thats what it is
supposed to mean.
==1854== Address 0x42193CB0 is 60 bytes inside a block of size 63 alloc'd
==1854== at 0x40166498: malloc (in /usr/lib/valgrind/valgrind.so)
==1854== by 0x40815A2E: trans_send (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
==1854== by 0x40813D63: evts_send (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
==1854== by 0x40814A0F: sync_call (in
/usr/local/touchtunes/lib/libttipc.so.0.0.0)
and this is what follows directly after the previous message.
funny, ("0x42193CB0" - ( decimal 60 )) == "0x42193C74"
which happens to be the pointer to my 63 byte long message.
Is there something wrong with address 0x42193CB0 ? why are my trailing
3 bytes no good or "nonaddressable" ?
might as well have said that:
"Address 0x42193CB1 is 61 bytes inside a block of size 63 alloc'd"
but how does that help me ?
Cheers all; any help is appriciated ;-)
-Tristan
PS:
valgrind-1.9.6
glibc-2.2
linux-2.4.16
|
|
From: Nicholas N. <nj...@ca...> - 2003-07-20 17:11:16
|
On Wed, 16 Jul 2003, Tristan Van Berkom wrote: > firstly, maybe there is an available FAQ for understanding vg output ? The user docs has some info: see developer.kde.org/~sewardj/docs-1.9.5/mc_main.html#mc-top, the section "Explanation of errors from Memcheck". > ==1854== Syscall param socketcall.sendto(msg) contains uninitialised or > unaddressable byte(s) > ==1854== at 0x408E2D92: __libc_sendto (in /lib/libc-2.1.3.so) > ==1854== by 0x40815AA6: trans_send (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > ==1854== by 0x40813D63: evts_send (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > ==1854== by 0x40814A0F: sync_call (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > > the "msg" param in my case is definitly initialized (even added memset > to be sure). now what could be meant by "unaddressable bytes" ? could > this be a result of sending a message of 63 bytes instead of 64 (meaning > only one of every 4 bytes is "truely addressable") ? I'm not feeding > `sendto' any register variables if thats what it is supposed to mean. > > ==1854== Address 0x42193CB0 is 60 bytes inside a block of size 63 alloc'd > ==1854== at 0x40166498: malloc (in /usr/lib/valgrind/valgrind.so) > ==1854== by 0x40815A2E: trans_send (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > ==1854== by 0x40813D63: evts_send (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > ==1854== by 0x40814A0F: sync_call (in > /usr/local/touchtunes/lib/libttipc.so.0.0.0) > > and this is what follows directly after the previous message. > funny, ("0x42193CB0" - ( decimal 60 )) == "0x42193C74" > which happens to be the pointer to my 63 byte long message. > Is there something wrong with address 0x42193CB0 ? why are my trailing > 3 bytes no good or "nonaddressable" ? > > might as well have said that: > "Address 0x42193CB1 is 61 bytes inside a block of size 63 alloc'd" The two parts of the error go together, the first part tells you where in the code it happens (in this case the actual line isn't identified because it's in a library that has had debug info stripped), the second tells you what memory is uninitialised/unaddressable (the byte or bytes starting at 0x42193CB0) and how/where that memory was allocated. Since the memory is within a malloc'd block (so says the 2nd part of the message) it should be addressable. But you say it's also initialised. A quick way to find out whether it's unaddressable or uninitialised is to try the "Addrcheck" skin -- run "valgrind --skin=addrcheck ...". Addrcheck only detects addressibility errors so that will tell you whether you have an addressability or uninitialised problem. Without the code for the program, it's hard to tell any more than that. If you can reduce your program down to a small, complete example and post that, that would be very helpful. N |
|
From: <pa...@pa...> - 2003-07-20 20:35:28
|
Nicholas Nethercote wrote:
> Since the memory is within a malloc'd block (so says the 2nd part of
> the message) it should be addressable. But you say it's also
> initialised.
It is possible that the memory *was* initialized at some point,
but no longer is at the time of the syscall. E.g.
int main()
{
char buf[8];
int x;
memset(buf, 'a', sizeof(buf));
*(int *)buf = x; /* oops -- buf is "uninitialized" again */
write(1, buf, sizeof(buf));
return 0;
}
|
|
From: Tristan V. B. <va...@to...> - 2003-07-21 14:44:44
|
Paul Pluzhnikov wrote:
>Nicholas Nethercote wrote:
>
>
>
>>Since the memory is within a malloc'd block (so says the 2nd part of
>>the message) it should be addressable. But you say it's also
>>initialised.
>>
>>
>
>It is possible that the memory *was* initialized at some point,
>but no longer is at the time of the syscall. E.g.
>
>int main()
>{
> char buf[8];
> int x;
>
> memset(buf, 'a', sizeof(buf));
> *(int *)buf = x; /* oops -- buf is "uninitialized" again */
> write(1, buf, sizeof(buf));
>
> return 0;
>}
>
>
>
Good point. I found my bug by now but still dont know the connection to the
"unaddressable bytes" exactly (I had a race condition where I was recieving
old packets and mistaking them for a "synchronous response") I have a
feeling
the VG message had something to do with variable length packet
structures but
thats just a guess.
Thanks all,
-Tristan
|