|
From: Benny C. <bwl...@gm...> - 2005-03-29 16:22:33
|
Hi,
First, many thanks for solving the previous problem about valgrind-2.4.0.
Now I get another question -- this time should be purely my own program bug.
Here is one of the errors shown when my program is run with valgrind memcheck:
==14078== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==14078== at 0x1BAD90D1: sendto (in /mnt/nfsroot/lib/tls/libc-2.3.2.so)
==14078== by 0x80559F0: mysend(int, int) (dsmcomm.cpp:1259)
==14078== by 0x8057C8D: getsegserver(dsmmsg) (dsmall.cpp:988)
==14078== by 0x8053AB7: msgserver() (dsmcomm.cpp:439)
==14078== by 0x8054408: sigio_handler() (dsmcomm.cpp:728)
==14078== by 0x1BA24A17: (within /mnt/nfsroot/lib/tls/libc-2.3.2.so)
==14078== by 0x80537A0: enable_sigio() (dsmcomm.cpp:314)
==14078== by 0x804DA0C: fasttouch(unsigned, unsigned, unsigned) (dsm.h:1017)
==14078== by 0x804B52D: Pointer<Pointer<float> >::operator[](int)
(dsm.h:2424)
==14078== by 0x8049683: main (dsminit-sor.cpp:185)
==14078== Address 0x1021306E is not stack'd, malloc'd or (recently) free'd
I should be sending bytes from 0x10213040 to 0x1021306D.
But what does the last line suggest?
For your information, the sending routine is called like this:
res = sendto(sendfd[toproc], (char *)&(msgq[key]),
msgq[key].size + 32, 0, (struct sockaddr *)&to[toproc],
sizeof(to[toproc]));
where msgq[] is defined like this in global:
struct dsmmsg msgq[2048];
and struct dsmmsg looks like this:
struct dsmmsg {
unsigned short int op, subseq, ref, endflag;
int frompid, topid, seqno, size;
struct dsmmsg *refp;
char *outbuff;
char data[65536];
};
Thanks and Best Regards,
Benny.
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 00:20:54
|
On Tue, 29 Mar 2005, Benny Cheung wrote: > ==14078== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) > ==14078== at 0x1BAD90D1: sendto (in /mnt/nfsroot/lib/tls/libc-2.3.2.so) > ==14078== by 0x80559F0: mysend(int, int) (dsmcomm.cpp:1259) > ==14078== by 0x8057C8D: getsegserver(dsmmsg) (dsmall.cpp:988) > ==14078== by 0x8053AB7: msgserver() (dsmcomm.cpp:439) > ==14078== by 0x8054408: sigio_handler() (dsmcomm.cpp:728) > ==14078== by 0x1BA24A17: (within /mnt/nfsroot/lib/tls/libc-2.3.2.so) > ==14078== by 0x80537A0: enable_sigio() (dsmcomm.cpp:314) > ==14078== by 0x804DA0C: fasttouch(unsigned, unsigned, unsigned) (dsm.h:1017) > ==14078== by 0x804B52D: Pointer<Pointer<float> >::operator[](int) > (dsm.h:2424) > ==14078== by 0x8049683: main (dsminit-sor.cpp:185) > ==14078== Address 0x1021306E is not stack'd, malloc'd or (recently) free'd > > I should be sending bytes from 0x10213040 to 0x1021306D. > But what does the last line suggest? It just means that the memory involved is not on the stack or on the heap. This makes sense, since your array is global. > For your information, the sending routine is called like this: > > res = sendto(sendfd[toproc], (char *)&(msgq[key]), > msgq[key].size + 32, 0, (struct sockaddr *)&to[toproc], > sizeof(to[toproc])); > > where msgq[] is defined like this in global: > > struct dsmmsg msgq[2048]; Looks like you've gone one past the end of an array. N |
|
From: Benny C. <bwl...@gm...> - 2005-03-30 11:49:18
|
Hi, Nicholas Nethercote <njn <at> cs.utexas.edu> writes: > > ==14078== Address 0x1021306E is not stack'd, malloc'd or (recently) free'd > > > > I should be sending bytes from 0x10213040 to 0x1021306D. > > But what does the last line suggest? > > It just means that the memory involved is not on the stack or on the heap. > This makes sense, since your array is global. > > > For your information, the sending routine is called like this: > > > > res = sendto(sendfd[toproc], (char *)&(msgq[key]), > > msgq[key].size + 32, 0, (struct sockaddr *)&to[toproc], > > sizeof(to[toproc])); > > > > where msgq[] is defined like this in global: > > > > struct dsmmsg msgq[2048]; > > Looks like you've gone one past the end of an array. It does not seem to be the case, since I have printed the value of key, it is 2047, and I have also printed the address range occupied by msgq[2047], which is [0x10213040, 0x10223060). So the address printed by Valgrind 0x1021306E should be valid. Anyway, thanks for your answer. Any other possibilites for this error? Best Regards, Benny. |