|
From: John R.
|
> ==20943== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
> ==20943== at 0x40FF938: sendto (in /lib/libc-2.4.so)
> ==20943== by 0x804FC66: infospace_action_send_answer
> rc = sendto (sd, buffer,
> bufflen,
> 0,
> (struct sockaddr *) &remoteServAddr,
> sizeof (remoteServAddr));
sendto(...) is really sys_socket(11, &...):
(gdb) x/12i sendto
0x5fb450 <sendto>: cmpl $0x0,%gs:0xc # threads make life complicated
0x5fb458 <sendto+8>: jne 0x5fb479 <sendto+41>
0x5fb45a <sendto+10>: mov %ebx,%edx # save register over system call
0x5fb45c <sendto+12>: mov $0x66,%eax # __NR_socketcall <asm/unistd.h>
0x5fb461 <sendto+17>: mov $0xb,%ebx # SYS_SENDTO sub-case <linux/net.h>
0x5fb466 <sendto+22>: lea 0x4(%esp),%ecx # address of 1st arg to sendto()
0x5fb46a <sendto+26>: call *%gs:0x10
If the number of arguments to sendto() is less than the maximum
of some other sys_socket(n,...) case, and if memcheck does not
distinguish the cases based on the sub-case in %ebx ("0xb"), then
some un-written word on the stack, following the last parameter
to sendto(), may be counted against sendto().
However, it seems that sendto() and recvfrom() have the longest
argument lists of any __NR_socketcall, so that may not be the problem.
Another thing to consider is the declaration:
----- <bits/socket.h>
/* Structure describing a generic socket address. */
struct sockaddr
{
__SOCKADDR_COMMON (sa_); /* Common data: address family and length. */
char sa_data[14]; /* Address data. */
};
-----
which looks highly suspicious. It's really a union of many things,
and probably not all of the cases initialize all 14 of the bytes,
and memcheck may be excused from the excessive complexity involved
in knowing exactly which bytes are used by exactly which subcases.
So check the declaration of "(struct sockaddr *) &remoteServAddr".
The fix probably is "memset(&remoteServAddr, 0, sizeof(remoteServAddr));"
before any other uses of remoteServAddr.
--
|
|
From: Christian K. <chr...@si...> - 2007-06-25 11:34:34
|
Thanks for the suggestions, The problem was, that there was an unitialized value in the send buffer at position 300. This value was interpreted by the valgrind memchecker as a pointer and le to the error. Initializing the buffer at positions 300 .. 303 fixed the problem all the best Christian Kleegrewe |