|
From: Cippo L. <cip...@ya...> - 2006-06-27 15:03:54
|
hi all, i'm new of this m.l. I'm write here because i has a problem and i'm not able to understand if it is caused by my c code or from same error into glibc libraries. I has got a lot of message like this: ==2321== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==2321== at 0x4048541: sendto (in /lib/tls/libpthread.so) ==2321== by 0x804D05B: send_and_retrive (second_level.c:1130) ==2321== by 0x804E032: ask_peer_list (third_level.c:597) ==2321== by 0x8049265: main (client.c:239) ==2321== Address 0xBEFE3B72 is on thread 1's stack and so i thought to some glibc error, but at the end, into valgrind summary i has: ==2321== LEAK SUMMARY: ==2321== definitely lost: 2,650 bytes in 80 blocks. ==2321== possibly lost: 2,380 bytes in 35 blocks. ==2321== still reachable: 2,194 bytes in 49 blocks. ==2321== suppressed: 0 bytes in 0 blocks. so i think it is impossible that all these erros are due to some mistake into glibc. Someone can give me some advices, please? thanks for your time. Alberto P.S. I already read the valgrind howto: http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: <nea...@ti...> - 2006-06-28 09:12:59
|
hi all, i'm new of this m.l. I'm write here because i has a problem and i'm not able to understand if it is caused by my c code or from same error into glibc libraries. I has got a lot of message like this: ==2321== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==2321== at 0x4048541: sendto (in /lib/tls/libpthread.so) ==2321== by 0x804D05B: send_and_retrive (second_level.c:1130) ==2321== by 0x804E032: ask_peer_list (third_level.c:597) ==2321== by 0x8049265: main (client.c:239) ==2321== Address 0xBEFE3B72 is on thread 1's stack and so i thought to some glibc error, but at the end, into valgrind summary i has: ==2321== LEAK SUMMARY: ==2321== definitely lost: 2,650 bytes in 80 blocks. ==2321== possibly lost: 2,380 bytes in 35 blocks. ==2321== still reachable: 2,194 bytes in 49 blocks. ==2321== suppressed: 0 bytes in 0 blocks. so i think it is impossible that all these erros are due to some mistake into glibc. Someone can give me some advices, please? thanks for your time. Alberto P.S. I already read the valgrind howto: http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html P.P.S. i already sent this question but i never received an answer...so i tried to unsubscrib this m.l. with my previous email address and subscribe a new account with this other...please if someone read this, even if has no answer can send me an email? ...a pong response :) so i know that subscription is ok. Thanks all -- Alberto Negri Undergraduate student at Computer Science, University of Bologna. Icq number: 79465051 Web page: www.cs.unibo.it/~negri Gpg-id: 1024D/E96025D7 Fingerprint: 2C6A 3E88 05AB 5B21 82E8 4A80 C357 1E37 E960 25D7 |
|
From: Tom H. <to...@co...> - 2006-06-28 09:22:26
|
In message <20060628111249.79953c79@localhost>
nea...@ti... wrote:
> I has got a lot of message like this:
>
> ==2321== Syscall param socketcall.sendto(msg) points to uninitialised
> byte(s)
> ==2321== at 0x4048541: sendto (in /lib/tls/libpthread.so)
> ==2321== by 0x804D05B: send_and_retrive (second_level.c:1130)
> ==2321== by 0x804E032: ask_peer_list (third_level.c:597)
> ==2321== by 0x8049265: main (client.c:239)
> ==2321== Address 0xBEFE3B72 is on thread 1's stack
Most likely you are calling send() to send a structure that has
padding bytes in it - impossible to say for sure without seeing
the source. It's unlikely to be a glibc problem though.
> and so i thought to some glibc error, but at the end, into valgrind
> summary i has:
>
> ==2321== LEAK SUMMARY:
> ==2321== definitely lost: 2,650 bytes in 80 blocks.
> ==2321== possibly lost: 2,380 bytes in 35 blocks.
> ==2321== still reachable: 2,194 bytes in 49 blocks.
> ==2321== suppressed: 0 bytes in 0 blocks.
>
> so i think it is impossible that all these erros are due to some
> mistake into glibc.
The memory leaks are a completely separate issue, and without seeing
the details of the leaks (use --leak-check=full to get these) it is not
possible to know where the leaks are coming from.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Stewart S. <st...@fl...> - 2006-06-28 13:17:10
|
On Wed, 2006-06-28 at 10:22 +0100, Tom Hughes wrote:
> In message <20060628111249.79953c79@localhost>
> nea...@ti... wrote:
>=20
> > I has got a lot of message like this:
> >
> > =3D=3D2321=3D=3D Syscall param socketcall.sendto(msg) points to uniniti=
alised
> > byte(s)
> > =3D=3D2321=3D=3D at 0x4048541: sendto (in /lib/tls/libpthread.so)
> > =3D=3D2321=3D=3D by 0x804D05B: send_and_retrive (second_level.c:1130=
)
> > =3D=3D2321=3D=3D by 0x804E032: ask_peer_list (third_level.c:597)
> > =3D=3D2321=3D=3D by 0x8049265: main (client.c:239)
> > =3D=3D2321=3D=3D Address 0xBEFE3B72 is on thread 1's stack
>=20
> Most likely you are calling send() to send a structure that has=20
> padding bytes in it - impossible to say for sure without seeing
> the source. It's unlikely to be a glibc problem though.
this can also cause compatibility problems between platforms.
e.g.
struct { uint32, uint64} will be 128bits on linux ppc32, but 96 on osx
ppc32 and x86.
there's the __attribute__ packed as well as a warning (forget what it
is) that you can switch on to find these structures.
--=20
Stewart Smith (st...@fl...)
http://www.flamingspork.com/
|
|
From: <nea...@ti...> - 2006-06-28 15:06:08
|
As first i would like to say that i'm NOT a good c programmer...so sorry for my bad c code! :)
I wrote here because it would be strange that could be a library problem....
On Wed, 28 Jun 2006 10:22:04 +0100
Tom Hughes <to...@co...> wrote:
> In message <20060628111249.79953c79@localhost>
> nea...@ti... wrote:
>
> > I has got a lot of message like this:
> >
> > ==2321== Syscall param socketcall.sendto(msg) points to uninitialised
> > byte(s)
> > ==2321== at 0x4048541: sendto (in /lib/tls/libpthread.so)
> > ==2321== by 0x804D05B: send_and_retrive (second_level.c:1130)
> > ==2321== by 0x804E032: ask_peer_list (third_level.c:597)
> > ==2321== by 0x8049265: main (client.c:239)
> > ==2321== Address 0xBEFE3B72 is on thread 1's stack
>
> Most likely you are calling send() to send a structure that has
> padding bytes in it - impossible to say for sure without seeing
> the source. It's unlikely to be a glibc problem though.
This is my code(the most important part):
//caller:
data_package pkg;
if(send_data(&pkg,sizeof(pkg),client,sockfd)!=GOOD)
{
return ERROR;
}
//where pkg is:
typedef struct
{
unsigned char protocol_type;
unsigned char type;
unsigned int pkg_dim;
unsigned int data_dim;
char caller;
unsigned short int pthread;
int ip;/*peer's ip address. it is a sockaddr_in.sin_addr.s_addr
field*/ int cout;/*cyclon output port*/
int cin;/*cyclon input port*/
int vout;/*vicinity output port*/
int vin;/*vicinity input port*/
long int ranking;
char data[DIM_DATA_PACK];
} data_package;
//callee:
int send_data(data_package *data,int dim,struct sockaddr_in *client, int socket)
{
int ret_val;
int counter=0;
while(1)
{
ret_val=sendto(socket,(data+counter),dim-counter,0,(struct sockaddr *)client,sizeof(struct sockad\
dr));
if(ret_val==-1 && errno==EINTR)
{
continue;
}
if(ret_val==-1 && errno!=EINTR)
{
return ERROR;/*There was an error*/
}
counter=counter+ret_val;
if(counter>=dim)
{
break;/*I will go out from infinite loop*/
}
}
return GOOD;
}
i did not undestood what do you mean with padding bytes into a data structure. Could you help me, please?
thanks!
> > and so i thought to some glibc error, but at the end, into valgrind
> > summary i has:
> >
> > ==2321== LEAK SUMMARY:
> > ==2321== definitely lost: 2,650 bytes in 80 blocks.
> > ==2321== possibly lost: 2,380 bytes in 35 blocks.
> > ==2321== still reachable: 2,194 bytes in 49 blocks.
> > ==2321== suppressed: 0 bytes in 0 blocks.
> >
> > so i think it is impossible that all these erros are due to some
> > mistake into glibc.
>
> The memory leaks are a completely separate issue, and without seeing
> the details of the leaks (use --leak-check=full to get these) it is not
> possible to know where the leaks are coming from.
I tried to restart valgrind with that param but the output looks like the same:
==32681== Syscall param socketcall.sendto(msg) points to uninitialised
byte(s) ==32681== at 0x40ED37C: sendto (in /lib/libc-2.3.6.so)
==32681== by 0x804A9B9: ans_retry (second_level.c:882)
==32681== by 0x804C521: ans_peer_list (fourth_level.c:66)
==32681== by 0x804CA72: handle_connection (server.c:351)
==32681== by 0x804C88E: messages (server.c:248)
==32681== by 0x804C761: server (server.c:177)
==32681== by 0x804C692: main (server.c:129)
==32681== Address 0xBEF37EA2 is on thread 1's stack
==32681== ERROR SUMMARY: 7 errors from 3 contexts (suppressed: 13 from
==32681== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32681== malloc/free: 685 allocs, 685 frees, 72,138 bytes allocated.
==32681== For counts of detected errors, rerun with: -v
==32681== All heap blocks were freed -- no leaks are possible.
the strange thing is that here:
http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html#closerview
at 4.2.3.4. Mismatched Use of Functions is written that an error like mine means that i cleared the memory with a wrong command;
i.e. i should use a delete[] to free the memory allocated with a malloc...but into my code i used only calloc (to avoid data not initialized), realloc, and free.
Ah the numbers showed into this other summary is different because my application has to work into an infinite loop, so
code problems became as bigger as i leave the program run...i hope to be "understandable".
Is it worse my c code or my english? :D
> Tom
thanks for your precious help.
Alberto
> --
> Tom Hughes (to...@co...)
> http://www.compton.nu/
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Nicholas N. <nj...@cs...> - 2006-06-28 23:14:24
|
On Wed, 28 Jun 2006 nea...@ti... wrote:
>> Most likely you are calling send() to send a structure that has
>> padding bytes in it - impossible to say for sure without seeing
>> the source. It's unlikely to be a glibc problem though.
>
> //where pkg is:
> typedef struct
> {
> unsigned char protocol_type;
> unsigned char type;
> unsigned int pkg_dim;
> unsigned int data_dim;
> char caller;
> unsigned short int pthread;
> int ip;/*peer's ip address. it is a sockaddr_in.sin_addr.s_addr
> field*/ int cout;/*cyclon output port*/
> int cin;/*cyclon input port*/
> int vout;/*vicinity output port*/
> int vin;/*vicinity input port*/
> long int ranking;
> char data[DIM_DATA_PACK];
> } data_package;
>
> i did not undestood what do you mean with padding bytes into a data structure. Could you help me, please?
> thanks!
The C compiler is free to leave gaps in the memory layout of a struct.
It does this to ensure all values are aligned, eg. a 4-byte value is aligned
on a 4-byte boundary. This can improve performance on many machines.
In your struct above, the first int 'pkg_dim' will probably have two bytes
of padding before it in order to be 4-aligned. There will probably be
another byte of padding after 'caller'.
These padding bytes don't get written to if you just assign all the fields
individually. So they remain uninitialised. Then when you send a struct
through socketcall, Valgrind complains.
The workaround is to use calloc instead of malloc to allocate the memory, or
use memset(X, 0, sizeof(data_package)) to first zero out the whole struct if
it's on the stack.
> the strange thing is that here:
> http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html#closerview
> at 4.2.3.4. Mismatched Use of Functions is written that an error like mine means that i cleared the memory with a wrong command;
> i.e. i should use a delete[] to free the memory allocated with a malloc...but into my code i used only calloc (to avoid data not initialized), realloc, and free.
I think that's irrelevant here.
> Is it worse my c code or my english? :D
Your English is fine, and Valgrind can help with your C code :)
Nick
|
|
From: <nea...@ti...> - 2006-06-30 00:10:16
|
On Thu, 29 Jun 2006 09:14:02 +1000 (EST)
Nicholas Nethercote <nj...@cs...> wrote:
> On Wed, 28 Jun 2006 nea...@ti... wrote:
>
> >> Most likely you are calling send() to send a structure that has
> >> padding bytes in it - impossible to say for sure without seeing
> >> the source. It's unlikely to be a glibc problem though.
> >
> > //where pkg is:
> > typedef struct
> > {
> > unsigned char protocol_type;
> > unsigned char type;
> > unsigned int pkg_dim;
> > unsigned int data_dim;
> > char caller;
> > unsigned short int pthread;
> > int ip;/*peer's ip address. it is a sockaddr_in.sin_addr.s_addr
> > field*/ int cout;/*cyclon output port*/
> > int cin;/*cyclon input port*/
> > int vout;/*vicinity output port*/
> > int vin;/*vicinity input port*/
> > long int ranking;
> > char data[DIM_DATA_PACK];
> > } data_package;
> >
> > i did not undestood what do you mean with padding bytes into a data structure. Could you help me, please?
> > thanks!
>
> The C compiler is free to leave gaps in the memory layout of a struct.
> It does this to ensure all values are aligned, eg. a 4-byte value is aligned
> on a 4-byte boundary. This can improve performance on many machines.
>
> In your struct above, the first int 'pkg_dim' will probably have two bytes
> of padding before it in order to be 4-aligned. There will probably be
> another byte of padding after 'caller'.
>
> These padding bytes don't get written to if you just assign all the fields
> individually. So they remain uninitialised. Then when you send a struct
> through socketcall, Valgrind complains.
>
> The workaround is to use calloc instead of malloc to allocate the memory, or
> use memset(X, 0, sizeof(data_package)) to first zero out the whole struct if
> it's on the stack.
Using your advice i was able to reduce valgrind errors, but now i cannot understand theese other:
==11449== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==11449== malloc/free: in use at exit: 20,503 bytes in 634 blocks.
==11449== malloc/free: 747 allocs, 113 frees, 27,217 bytes allocated.
==11449== For counts of detected errors, rerun with: -v
==11449== searching for pointers to 634 not-freed blocks.
==11449== checked 158,596 bytes.
==11449==
==11449== 2,210 bytes in 5 blocks are still reachable in loss record 1 of 2
==11449== at 0x401A524: malloc(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==11449== by 0x8099699: xrealloc (in /bin/bash)
==11449== by 0x8088B28: (within /bin/bash)
==11449== by 0x8088D07: fd_to_buffered_stream (in /bin/bash)
==11449== by 0x8089261: with_input_from_buffered_stream (in /bin/bash)
==11449== by 0x805D877: main (in /bin/bash)
==11449==
==11449==
==11449== 18,293 bytes in 629 blocks are still reachable in loss record 2 of 2
==11449== at 0x401A524: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==11449== by 0x8099606: xmalloc (in /bin/bash)
==11449== by 0x8094705: set_default_locale (in /bin/bash)
==11449== by 0x805CA90: main (in /bin/bash)
==11449==
==11449== LEAK SUMMARY:
==11449== definitely lost: 0 bytes in 0 blocks.
==11449== possibly lost: 0 bytes in 0 blocks.
==11449== still reachable: 20,503 bytes in 634 blocks.
==11449== suppressed: 0 bytes in 0 blocks.
Someone can help me, please?
This seems to not be related to my c code...there are not any reference to my c files....but probably i'm wrong...
if you need further information...ask...i will answer as soon as possible. :)
> > the strange thing is that here:
> > http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html#closerview
> > at 4.2.3.4. Mismatched Use of Functions is written that an error like mine means that i cleared the memory with a wrong command;
> > i.e. i should use a delete[] to free the memory allocated with a malloc...but into my code i used only calloc (to avoid data not initialized), realloc, and free.
>
> I think that's irrelevant here.
Ok ;)
> > Is it worse my c code or my english? :D
>
> Your English is fine, and Valgrind can help with your C code :)
Infact i used it a lot before ask here, so i solved a lot of problem with my c code, but i think that my code is not "professional".
I mean that i don't use code like this: uint32, uint64, instead of: char, int... i know that some of them are "alias", but that
code appear more "professional" that mine...and this kind of "problems" are not solvable from valgrind! ...and my english is surely worse than my c code...and for it there is no valgrind like tool... :'(
Anyway thanks for your support.
> Nick
Alberto
|
|
From: Nicholas N. <nj...@cs...> - 2006-06-30 00:29:01
|
On Fri, 30 Jun 2006 nea...@ti... wrote: > ==11449== 2,210 bytes in 5 blocks are still reachable in loss record 1 of 2 > ==11449== at 0x401A524: malloc(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > ==11449== by 0x8099699: xrealloc (in /bin/bash) > ==11449== by 0x8088B28: (within /bin/bash) > ==11449== by 0x8088D07: fd_to_buffered_stream (in /bin/bash) > ==11449== by 0x8089261: with_input_from_buffered_stream (in /bin/bash) > ==11449== by 0x805D877: main (in /bin/bash) > ==11449== > ==11449== > ==11449== 18,293 bytes in 629 blocks are still reachable in loss record 2 of 2 > ==11449== at 0x401A524: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > ==11449== by 0x8099606: xmalloc (in /bin/bash) > ==11449== by 0x8094705: set_default_locale (in /bin/bash) > ==11449== by 0x805CA90: main (in /bin/bash) > ==11449== suppressed: 0 bytes in 0 blocks. > > Someone can help me, please? > This seems to not be related to my c code...there are not any reference to my c files....but probably i'm wrong... > if you need further information...ask...i will answer as soon as possible. :) They are memory leaks. The "(in /bin/bash)" part indicates that they are leaks in /bin/bash, so you can probably ignore (suppress) them. Are you running your C program from a bash script? If so, are you using --trace-children=yes? Nick |
|
From: <nea...@ti...> - 2006-06-30 09:58:51
|
On Fri, 30 Jun 2006 10:28:56 +1000 (EST)
Nicholas Nethercote <nj...@cs...> wrote:
> On Fri, 30 Jun 2006 nea...@ti... wrote:
>
> > ==11449== 2,210 bytes in 5 blocks are still reachable in loss record 1 of 2
> > ==11449== at 0x401A524: malloc(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> > ==11449== by 0x8099699: xrealloc (in /bin/bash)
> > ==11449== by 0x8088B28: (within /bin/bash)
> > ==11449== by 0x8088D07: fd_to_buffered_stream (in /bin/bash)
> > ==11449== by 0x8089261: with_input_from_buffered_stream (in /bin/bash)
> > ==11449== by 0x805D877: main (in /bin/bash)
> > ==11449==
> > ==11449==
> > ==11449== 18,293 bytes in 629 blocks are still reachable in loss record 2 of 2
> > ==11449== at 0x401A524: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> > ==11449== by 0x8099606: xmalloc (in /bin/bash)
> > ==11449== by 0x8094705: set_default_locale (in /bin/bash)
> > ==11449== by 0x805CA90: main (in /bin/bash)
> > ==11449== suppressed: 0 bytes in 0 blocks.
> >
> > Someone can help me, please?
> > This seems to not be related to my c code...there are not any reference to my c files....but probably i'm wrong...
> > if you need further information...ask...i will answer as soon as possible. :)
>
> They are memory leaks. The "(in /bin/bash)" part indicates that they are
> leaks in /bin/bash, so you can probably ignore (suppress) them. Are you
> running your C program from a bash script? If so, are you using
> --trace-children=yes?
ok! Now my valgrind command is this:
valgrind --leak-check=full --leak-check=yes --show-reachable=yes --trace-children=yes --log-file=server.log ./giano_server INADDR_ANY 5000
and i called directly the executable with valgrind...so now i has no more that kind of problems, but...
even if i cleaned all memory as you suggested me, i get theese errors:
==1636== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1636== at 0x40EE37C: sendto (in /lib/libc-2.3.6.so)
==1636== by 0x804AA17: ans_retry (second_level.c:796)
==1636== by 0x804C541: ans_peer_list (fifth_level.c:65)
==1636== by 0x804CA92: handle_connection (server.c:352)
==1636== by 0x804C8AE: messages (server.c:249)
==1636== by 0x804C781: server (server.c:178)
==1636== by 0x804C6B2: main (server.c:130)
==1636== Address 0xBEB04DF0 is on thread 1's stack
==1636==
==1636== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1636== at 0x40EE37C: sendto (in /lib/libc-2.3.6.so)
==1636== by 0x804C378: peer_list (fourth_level.c:103)
==1636== by 0x804C579: ans_peer_list (fifth_level.c:76)
==1636== by 0x804CA92: handle_connection (server.c:352)
==1636== by 0x804C8AE: messages (server.c:249)
==1636== by 0x804C781: server (server.c:178)
==1636== by 0x804C6B2: main (server.c:130)
==1636== Address 0xBEB03DB0 is on thread 1's stack
==1636==
==1636== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1636== at 0x40EE37C: sendto (in /lib/libc-2.3.6.so)
==1636== by 0x804C475: peer_list (fourth_level.c:134)
==1636== by 0x804C579: ans_peer_list (fifth_level.c:76)
==1636== by 0x804CA92: handle_connection (server.c:352)
==1636== by 0x804C8AE: messages (server.c:249)
==1636== by 0x804C781: server (server.c:178)
==1636== by 0x804C6B2: main (server.c:130)
==1636== Address 0xBEB04DE0 is on thread 1's stack
==1636==
==1636== ERROR SUMMARY: 7 errors from 3 contexts (suppressed: 13 from 1)
==1636== malloc/free: in use at exit: 0 bytes in 0 blocks.
==1636== malloc/free: 73 allocs, 73 frees, 9,969 bytes allocated.
==1636== For counts of detected errors, rerun with: -v
==1636== All heap blocks were freed -- no leaks are possible.
and i.e. with reference to first valgrind error i has this simple routine:
int ans_retry(int sockfd,struct sockaddr_in *client,gianostr *ginfo)
{
data_package pkg;
/*the file does not exits. I must tell to peer to try again between some seconds.*/
/*create a package containing the message (try again between some seconds)*/
/*Sending a try-later message:*/
/*Filling:*/
/* bzero(&pkg,sizeof(data_package));*/
memset(&pkg,0,sizeof(data_package));
if(fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,ginfo,&pkg)!=GOOD)
{
#if (DEBUG & 0x02)>0
printf("second_level.c: ans_retry: unable to create data
package 1.\n"); #endif
return ERROR;
}
/*sending package:*/
if(send_data(&pkg,sizeof(pkg),client,sockfd)!=GOOD)
{
#if (DEBUG & 0x02)>0
printf("second_level.c: ans_retry: unable to send data
package\n"); #endif
return ERROR;
}
return GOOD;
}
As you can see usually i prefer to use bzero, at the end i tried memset too, but results are the same.
int fill_package(unsigned char protocol,unsigned char type,char *data,int dim,gianostr *ginfo,data_packa\
ge *package)
{
if((dim==0 && data!=NULL) || (dim!=0 && data==NULL))
{/*something goes wrong*/
#if (DEBUG & 0x01)>0
printf("first_level.c: fill_package: invalid argument\n");
#endif
return ERROR;
}
package->protocol_type=protocol;
package->type=type;
if(data!=NULL)
{
package->data_dim=dim;
memcpy(package->data,data,dim);
}else{
package->data_dim=0;
bzero((void *)package->data,DIM_DATA_PACK);
}
package->caller=ginfo->caller;
package->pthread=ginfo->pthread;
package->ip=ginfo->ip;
package->cout=ginfo->cout;
package->cin=ginfo->cin;
package->vout=ginfo->vout;
package->vin=ginfo->vin;
package->ranking=ginfo->ranking;
package->pkg_dim=sizeof((*package));
#if (DEBUG & 0x01)>0
printf("first_level.c: fill_package:
pkg_dim=%d\n",package->pkg_dim); #endif
return GOOD;
}
the send_data routine is the same that i previously posted here.
> Nick
Alberto
|
|
From: <nea...@ti...> - 2006-07-01 13:35:21
|
Sorry if i spam you, but i'm not able to understand where is my error:
I tried to create a little test program:
int ref(data_package *pkg)
{
gianostr ginfo;
/* bzero(&ginfo,sizeof(gianostr));*/
ginfo.caller=1;
ginfo.pthread=1;
ginfo.ip=-1;
ginfo.cout=5000;
ginfo.cin=5000;
ginfo.vout=5000;
ginfo.vin=5000;
ginfo.ranking=-1;
bzero(pkg,sizeof(data_package));
dump_package(pkg);
fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,&ginfo,pkg);
dump_package(pkg);
}
int main()
{
data_package pkg;
ref(&pkg);
return 0;
}
that, as you can see, uses my routines, and valgrind(valgrind --leak-check=full --leak-check=yes --show-reachable=yes
--trace-children=yes ./fill_package) reports no error:
==32649== Memcheck, a memory error detector.
==32649== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==32649== Using LibVEX rev 1606, a library for dynamic binary translation.
==32649== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32649== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==32649== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==32649== For more details, rerun with: -v
==32649==
...output...
==32649==
==32649== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==32649== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32649== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==32649== For counts of detected errors, rerun with: -v
==32649== All heap blocks were freed -- no leaks are possible.
but when i try to use the same functions into my program(with the same command line options):
int ans_retry(int sockfd,struct sockaddr_in *client,gianostr *ginfo)
{
data_package pkg;
if(fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,ginfo,&pkg)!=GOOD)
{
#if (DEBUG & 0x02)>0
printf("second_level.c: ans_retry: unable to create data package 1.\n");
#endif
return ERROR;
}
dump_package(&pkg);
...
}
i get this error:
==32586== Use of uninitialised value of size 4
==32586== at 0x407071C: (within /lib/libc-2.3.6.so)
==32586== by 0x40738A8: vfprintf (in /lib/libc-2.3.6.so)
==32586== by 0x40796FF: printf (in /lib/libc-2.3.6.so)
==32586== by 0x8049F07: dump_package (first_level.c:1403)
==32586== by 0x804AA5A: ans_retry (second_level.c:794)
==32586== by 0x804C501: ans_peer_list (fifth_level.c:65)
==32586== by 0x804CA98: handle_connection (server.c:342)
==32586== by 0x804C868: messages (server.c:249)
==32586== by 0x804C73C: server (server.c:178)
==32586== by 0x804C66E: main (server.c:130)
How could this be? fill_package and dump_package are the same!
I little changed my fill_package routine...but this could not be the problem...as i use it in both test and real programs.
If do you think that i should read something (book, or everything other please let me know that).
Any help will be appreciated.
Alberto
|
|
From: Tom H. <to...@co...> - 2006-07-01 14:02:48
|
In message <20060701153426.11b321e0@localhost>
nea...@ti... wrote:
> Sorry if i spam you, but i'm not able to understand where is my error:
>
> I tried to create a little test program:
>
> int ref(data_package *pkg)
> {
> gianostr ginfo;
>
> /* bzero(&ginfo,sizeof(gianostr));*/
> ginfo.caller=1;
> ginfo.pthread=1;
> ginfo.ip=-1;
> ginfo.cout=5000;
> ginfo.cin=5000;
> ginfo.vout=5000;
> ginfo.vin=5000;
> ginfo.ranking=-1;
>
> bzero(pkg,sizeof(data_package));
> dump_package(pkg);
> fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,&ginfo,pkg);
> dump_package(pkg);
> }
Here you are using bzero() on pkh before you call fill_package so
if dump_package() prints some part of pkg that fill_package() didn't
initialise then you won't get a warning as you have zeroed it all.
>
> but when i try to use the same functions into my program(with the same command line options):
>
> int ans_retry(int sockfd,struct sockaddr_in *client,gianostr *ginfo)
> {
> data_package pkg;
> if(fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,ginfo,&pkg)!=GOOD)
> {
> #if (DEBUG & 0x02)>0
> printf("second_level.c: ans_retry: unable to create data package 1.\n");
> #endif
> return ERROR;
> }
> dump_package(&pkg);
> ...
> }
>
> i get this error:
>
> ==32586== Use of uninitialised value of size 4
> ==32586== at 0x407071C: (within /lib/libc-2.3.6.so)
> ==32586== by 0x40738A8: vfprintf (in /lib/libc-2.3.6.so)
> ==32586== by 0x40796FF: printf (in /lib/libc-2.3.6.so)
> ==32586== by 0x8049F07: dump_package (first_level.c:1403)
> ==32586== by 0x804AA5A: ans_retry (second_level.c:794)
> ==32586== by 0x804C501: ans_peer_list (fifth_level.c:65)
> ==32586== by 0x804CA98: handle_connection (server.c:342)
> ==32586== by 0x804C868: messages (server.c:249)
> ==32586== by 0x804C73C: server (server.c:178)
> ==32586== by 0x804C66E: main (server.c:130)
>
> How could this be? fill_package and dump_package are the same!
But you haven't zeroed pkg...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <nea...@ti...> - 2006-07-01 14:13:13
|
On Sat, 01 Jul 2006 15:02:35 +0100
Tom Hughes <to...@co...> wrote:
> In message <20060701153426.11b321e0@localhost>
> nea...@ti... wrote:
>
> > Sorry if i spam you, but i'm not able to understand where is my error:
> >
> > I tried to create a little test program:
> >
> > int ref(data_package *pkg)
> > {
> > gianostr ginfo;
> >
> > /* bzero(&ginfo,sizeof(gianostr));*/
> > ginfo.caller=1;
> > ginfo.pthread=1;
> > ginfo.ip=-1;
> > ginfo.cout=5000;
> > ginfo.cin=5000;
> > ginfo.vout=5000;
> > ginfo.vin=5000;
> > ginfo.ranking=-1;
> >
> > bzero(pkg,sizeof(data_package));
> > dump_package(pkg);
> > fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,&ginfo,pkg);
> > dump_package(pkg);
> > }
>
> Here you are using bzero() on pkh before you call fill_package so
> if dump_package() prints some part of pkg that fill_package() didn't
> initialise then you won't get a warning as you have zeroed it all.
>
> >
> > but when i try to use the same functions into my program(with the same command line options):
> >
> > int ans_retry(int sockfd,struct sockaddr_in *client,gianostr *ginfo)
> > {
> > data_package pkg;
> > if(fill_package(SEMANTIC_OVERLAYS,ANS_TRY_LATER,NULL,0,ginfo,&pkg)!=GOOD)
> > {
> > #if (DEBUG & 0x02)>0
> > printf("second_level.c: ans_retry: unable to create data package 1.\n");
> > #endif
> > return ERROR;
> > }
> > dump_package(&pkg);
> > ...
> > }
> >
> > i get this error:
> >
> > ==32586== Use of uninitialised value of size 4
> > ==32586== at 0x407071C: (within /lib/libc-2.3.6.so)
> > ==32586== by 0x40738A8: vfprintf (in /lib/libc-2.3.6.so)
> > ==32586== by 0x40796FF: printf (in /lib/libc-2.3.6.so)
> > ==32586== by 0x8049F07: dump_package (first_level.c:1403)
> > ==32586== by 0x804AA5A: ans_retry (second_level.c:794)
> > ==32586== by 0x804C501: ans_peer_list (fifth_level.c:65)
> > ==32586== by 0x804CA98: handle_connection (server.c:342)
> > ==32586== by 0x804C868: messages (server.c:249)
> > ==32586== by 0x804C73C: server (server.c:178)
> > ==32586== by 0x804C66E: main (server.c:130)
> >
> > How could this be? fill_package and dump_package are the same!
>
> But you haven't zeroed pkg...
Sorry i forget to write my new fill_package:
int fill_package(unsigned char protocol,unsigned char type,char
*data,int dim,gianostr *ginfo,data_packa\ ge *package)
{
if((dim==0 && data!=NULL) || (dim!=0 && data==NULL) || package==NULL)
{/*something goes wrong*/
#if (DEBUG & 0x01)>0
printf("first_level.c: fill_package: invalid argument\n");
#endif
return ERROR;
}
bzero(package,sizeof(data_package));
bzero(package->data,DIM_DATA_PACK);
package->protocol_type=protocol;
package->type=type;
package->pkg_dim=sizeof(data_package);
package->data_dim=dim;
package->caller=ginfo->caller;
package->pthread=ginfo->pthread;
package->ip=ginfo->ip;
package->cout=ginfo->cout;
package->cin=ginfo->cin;
package->vout=ginfo->vout;
package->vin=ginfo->vin;
package->ranking=ginfo->ranking;
if(data!=NULL)
{
memcpy(package->data,data,dim);
}
return GOOD;
}
as you can see i will clear the memory any time i use fill_package...is for this reason that i cannot understand the problem.
> Tom
Alberto
|