|
From: Hannu V. <vu...@ms...> - 2011-12-16 08:41:55
|
Hello grinders!
I'm fresh to valgrind and started with one of my projects. I can't figure out why this kind of error comes from reading and writing to file.
I wrote small test case which gave same Conditional jump or move depends on uninitialised value errors.
#include <stdio.h>
#include <stdlib.h>
int main(){
char * buffer;
size_t size;
if(getline(&buffer, &size, stdin) >0){
fputs(buffer, stdout);
free(buffer);
}
}
What I'm doing wrong? Should I use fread and fwrite?
best regards,
Hannu Vuolasaho
|
|
From: Tom H. <to...@co...> - 2011-12-16 08:53:30
|
On 16/12/11 08:41, Hannu Vuolasaho wrote:
> I wrote small test case which gave same Conditional jump or move depends on uninitialised value errors.
>
> #include<stdio.h>
> #include<stdlib.h>
>
> int main(){
> char * buffer;
> size_t size;
>
> if(getline(&buffer,&size, stdin)>0){
> fputs(buffer, stdout);
> free(buffer);
> }
> }
>
> What I'm doing wrong? Should I use fread and fwrite?
You didn't initialise buffer to NULL before calling getline so it's
behaviour is not deterministic. In particular when it checks whether the
argument is NULL so as to decide whether to allocate a buffer it will be
checking an uninitialised value.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Hannu V. <vu...@ms...> - 2011-12-16 09:35:08
|
----------------------------------------
> Date: Fri, 16 Dec 2011 08:53:19 +0000
> From: to...@co...
> To: vu...@ms...
> CC: val...@li...
> Subject: Re: Conditional jump or move depends on uninitialised value and its reason
>
> On 16/12/11 08:41, Hannu Vuolasaho wrote:
>
> > I wrote small test case which gave same Conditional jump or move depends on uninitialised value errors.
> >
> > #include
> > #include
> >
> > int main(){
> > char * buffer;
> > size_t size;
> >
> > if(getline(&buffer,&size, stdin)>0){
> > fputs(buffer, stdout);
> > free(buffer);
> > }
> > }
> >
> > What I'm doing wrong? Should I use fread and fwrite?
>
> You didn't initialise buffer to NULL before calling getline so it's
> behaviour is not deterministic. In particular when it checks whether the
> argument is NULL so as to decide whether to allocate a buffer it will be
> checking an uninitialised value.
Yes I did. The evil copy eater before paste just ate it :) I saw that bug and forgot to paste fixed version.
I still get errors from puts().
I'm using Arch Linux and found old bug about strlen and SSE instructions among other thing. Also there was some posts about stripped libc and I have:
$ file /lib/libc-2.14.1.so
/lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x84c4a5b908da76082cff58f393bee5d9c15d9684, for GNU/Linux 2.6.27, stripped
Does that have something to do with puts() error?
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(){
char * buffer = NULL;
size_t size = 0;
int len = 0;
if(getline(&buffer, &size, stdin) >0 && buffer != NULL ){
if(strlen(buffer) > 0){
fputs(buffer, stdout);
}
}
if(buffer != NULL){
free(buffer);
}
}
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 ./read_test
==2001== Memcheck, a memory error detector
==2001== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2001== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2001== Command: ./read_test
==2001==
foo
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4EAB5FF: ??? (in /lib/libc-2.14.1.so)
==2001== by 0x4E9354D: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4E9DBBB: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4E9DC1F: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4E9DC28: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4E9F823: _IO_default_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Conditional jump or move depends on uninitialised value(s)
==2001== at 0x4E9F881: _IO_default_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
==2001== Use of uninitialised value of size 8
==2001== at 0x4E9F88B: _IO_default_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so)
==2001== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so)
==2001== by 0x400671: main (read_test.c:11)
==2001==
foo
==2001==
==2001== HEAP SUMMARY:
==2001== in use at exit: 0 bytes in 0 blocks
==2001== total heap usage: 1 allocs, 1 frees, 120 bytes allocated
==2001==
==2001== All heap blocks were freed -- no leaks are possible
==2001==
==2001== For counts of detected and suppressed errors, rerun with: -v
==2001== Use --track-origins=yes to see where uninitialised values come from
==2001== ERROR SUMMARY: 14 errors from 7 contexts (suppressed: 6 from 6)
|
|
From: Tom H. <to...@co...> - 2011-12-16 09:49:21
|
On 16/12/11 09:35, Hannu Vuolasaho wrote:
> I'm using Arch Linux and found old bug about strlen and SSE instructions among other thing. Also there was some posts about stripped libc and I have:
> $ file /lib/libc-2.14.1.so
> /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x84c4a5b908da76082cff58f393bee5d9c15d9684, for GNU/Linux 2.6.27, stripped
>
> Does that have something to do with puts() error?
>
> #include<stdio.h>
> #include<stdlib.h>
> #include<string.h>
>
> int main(){
> char * buffer = NULL;
> size_t size = 0;
> int len = 0;
> if(getline(&buffer,&size, stdin)>0&& buffer != NULL ){
> if(strlen(buffer)> 0){
> fputs(buffer, stdout);
> }
> }
> if(buffer != NULL){
> free(buffer);
> }
> }
That works fine for me:
==30413== Memcheck, a memory error detector
==30413== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30413== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30413== Command: ./xxx
==30413==
foo
foo
==30413==
==30413== HEAP SUMMARY:
==30413== in use at exit: 0 bytes in 0 blocks
==30413== total heap usage: 1 allocs, 1 frees, 120 bytes allocated
==30413==
==30413== All heap blocks were freed -- no leaks are possible
==30413==
==30413== For counts of detected and suppressed errors, rerun with: -v
==30413== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-12-16 10:05:56
|
> I still get errors from puts(). You could try --track-origins=yes to see where this uninit value comes from. (maybe it might be some optimisation of string handling in libc which should be ignored by the libc suppression file not exactly up to date for your system ?) ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Hannu V. <vu...@ms...> - 2011-12-16 11:18:46
|
> > I still get errors from puts(). > You could try --track-origins=yes to see where this uninit value comes > from. > > (maybe it might be some optimisation of string handling in libc which > should be > ignored by the libc suppression file not exactly up to date for your > system ?) I ran with -v and it told me I use /usr/lib/valgrind/default.supp -rw-r--r-- 1 root root 29668 14.11. 03:22 /usr/lib/valgrind/default.supp But that's not going to help much. And it didn't contain any version signature. Errors are coming from getdelim's mallocs. Hannu $ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-origins=yes ./read_test ==7252== Memcheck, a memory error detector ==7252== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==7252== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==7252== Command: ./read_test ==7252== foo ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4EAB5FF: ??? (in /lib/libc-2.14.1.so) ==7252== by 0x4E9354D: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4E9DBBB: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4E9DC1F: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4E9DC28: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4E9F823: _IO_default_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Conditional jump or move depends on uninitialised value(s) ==7252== at 0x4E9F881: _IO_default_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== ==7252== Use of uninitialised value of size 8 ==7252== at 0x4E9F88B: _IO_default_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E9DC39: _IO_file_xsputn (in /lib/libc-2.14.1.so) ==7252== by 0x4E935CC: fputs (in /lib/libc-2.14.1.so) ==7252== by 0x400671: main (read_test.c:11) ==7252== Uninitialised value was created by a heap allocation ==7252== at 0x4C2893D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7252== by 0x4E93EE1: getdelim (in /lib/libc-2.14.1.so) ==7252== by 0x40063F: main (read_test.c:9) ==7252== foo ==7252== ==7252== HEAP SUMMARY: ==7252== in use at exit: 0 bytes in 0 blocks ==7252== total heap usage: 1 allocs, 1 frees, 120 bytes allocated ==7252== ==7252== All heap blocks were freed -- no leaks are possible ==7252== ==7252== For counts of detected and suppressed errors, rerun with: -v ==7252== ERROR SUMMARY: 14 errors from 7 contexts (suppressed: 6 from 6) |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-12-16 11:52:51
|
> > I ran with -v and it told me I use /usr/lib/valgrind/default.supp > -rw-r--r-- 1 root root 29668 14.11. 03:22 > /usr/lib/valgrind/default.supp But that's not going to help > much. And it didn't contain any version signature. This is strange. Looking at my valgrind 3.7.0 installed default.supp, the 2nd line indicates from which 'source suppression files' it was generated from. Now, I guess that this problem is not caused by your code (both Tom and me find no problem on our installation). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: John R. <jr...@bi...> - 2011-12-17 01:18:05
|
> I'm using Arch Linux and found old bug about strlen and SSE instructions among other thing. Also there was some posts about stripped libc and I have: > $ file /lib/libc-2.14.1.so > /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x84c4a5b908da76082cff58f393bee5d9c15d9684, for GNU/Linux 2.6.27, stripped > > Does that have something to do with puts() error? Yes! *DO NOT USE* Arch Linux with valgrind! Arch Linux has blundered by stripping glibc and not supplying the debug info in some other way (such as in a corresponding glibc-debuginfo package, like Fedora Project.) This grave mistake will make life miserable for users of memcheck. Refer to the initial post to [Valgrind-users] by Dominic Monroe with subject "Valgrind 3.7 + GLibc 1.4.1" [sic] about three weeks ago on 11/25/2011; any my reply two days later. Invoke valgrind with the additional command-line parameter "--db-attach=yes" and look at the instructions which surround the error [done here with valgrind 3.7.0 on i686]: ==760== Conditional jump or move depends on uninitialised value(s) ==760== at 0x40AD029: ??? (in /lib/libc-2.14.1.so) ==760== by 0x409597D: fputs (in /lib/libc-2.14.1.so) ==760== by 0x804850F: main (main.c:11) ==760== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y (gdb) x/12i $pc-0x18 0x40ad011: xor %ecx,%edx 0x40ad013: and $0x1010100,%edx ### 0x40ad019: jne 0x40ad069 0x40ad01b: mov (%eax),%ecx 0x40ad01d: add $0x4,%eax 0x40ad020: sub %ecx,%edx 0x40ad022: add $0xfefefeff,%ecx ### 0x40ad028: dec %edx => 0x40ad029: jae 0x40ad069 0x40ad02b: xor %ecx,%edx 0x40ad02d: and $0x1010100,%edx ### 0x40ad033: jne 0x40ad069 Notice those constant values 0x1010100 and 0xfefefeff. Those are the hallmarks of optimized code which scans for the terminating '\0' character in a string, inspecting 4 bytes (one word) at a time. Memcheck does not understand such code, so memcheck replaces known subroutines with its own equivalent code. If the debug info has been stripped, then several such subroutines become invisible, memcheck does not replace them, and memcheck gets lost. Also notice that gdb prints hex addresses such as "0x40ad029" instead of a symbol name plus small offset. This indicates that gdb cannot find debug information for those instructions (because Arch Linux stripped it, and did not put it somewhere else where it is accessible to gdb.) *DO NOT USE* Arch Linux with memcheck! -- |
|
From: Hannu V. <vu...@ms...> - 2011-12-21 10:13:39
|
---------------------------------------- > Date: Fri, 16 Dec 2011 17:18:09 -0800 > From: jr...@bi... > To: val...@li... > Subject: Re: [Valgrind-users] Conditional jump or move depends on uninitialised value and its reason > > > I'm using Arch Linux and found old bug about strlen and SSE instructions among other thing. Also there was some posts about stripped libc and I have: > > $ file /lib/libc-2.14.1.so > > /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x84c4a5b908da76082cff58f393bee5d9c15d9684, for GNU/Linux 2.6.27, stripped > > > > Does that have something to do with puts() error? > > Yes! *DO NOT USE* Arch Linux with valgrind! Arch Linux has blundered > by stripping glibc and not supplying the debug info in some other way > (such as in a corresponding glibc-debuginfo package, like Fedora Project.) > This grave mistake will make life miserable for users of memcheck. Arch Linux rolled on and this was fixed. Valgrinding the test program success. I believe *DO NOT USE* can be lifted at least for this part and people who like Arch can continue their life :) $ file /lib/libc-2.14.1.so /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=0xf4efb4f05d82dd16df1dbc336dc750e6e80ef5f9, for GNU/Linux 2.6.27, not stripped Hannu Vuolasaho |