|
From: Tom H. <th...@cy...> - 2004-07-07 22:09:17
|
In message <108...@pe...>
Steven Dake <sd...@mv...> wrote:
> ==2834== Syscall param socketcall.recvmsg(msg.msg_iov[i] contains
> uninitialised or unaddressable byte(s)
> ==2834== at 0x3C111A16: sendmsg (socket.S:63)
> ==2834== by 0x8053371: message_handler_orf_token (gmi.c:2240)
> ==2834== by 0x8054779: recv_handler (gmi.c:3012)
> ==2834== by 0x8050876: poll_run (poll.c:458)
> ==2834== Address 0x3C182171 is 9 bytes inside a block of size 52
> alloc'd
> ==2834== at 0x3C01D2CB: malloc (vg_replace_malloc.c:105)
> ==2834== by 0x8050AC7: gmi_pend_trans_item_store (gmi.c:501)
> ==2834== by 0x8050F59: gmi_mcast (gmi.c:669)
> ==2834== by 0x804A52F: clmNodeJoinSend (clm.c:323)
>
> I'm not quite sure how to read this message.
>
> It says "at sendmsg" but the syscall param is "socketcall.recvmsg". So
> which one is it? I have cleaned up all uninitialized variables that
> could possibly be related so I'm a little stuck as to what to do next to
> remove this error.
I can't see anything in valgrind that would cause it to print recvmsg
when it should say sendmsg, and you do have recv_handler on the stack
so I suspect the sendmsg line in that stack trace is bogus. It may be
that the debug data is confused, or that recvmsg and sendmsg share part
of their implementation inside the C library or something.
> Also, what does the "address X is 9 bytes insid ea block of size 52
> alloced". does that tell where the iov[i] was allocated?
Basically, yes. It tells you where the block that contained the
uninitialised byte was allocated.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|