How do I identify which values values are uninitialised in valgrind? - c

This might seem like a silly question but valgrind doesn't by default give you quite enough information. Valgrind reports the following:
==2541== Conditional jump or move depends on uninitialised value(s)
==2541== at 0x401777: process_read.clone.3 (in /home/matt/dev/ocs/client3/a.out)
==2541== by 0x4026B8: obbs_main (in /home/matt/dev/ocs/client3/client)
==2541== by 0x53D1D8B: start_thread (pthread_create.c:304)
==2541== by 0x511D04C: clone (clone.S:112)
I can't see anything obvious. Valgrind -v also doesn't help.
Is there a way to get valgrind to tell me which values are uninitialsed?

If you use the --track-origins=yes flag with valgrind it will tell you the line number (assuming you compiled with -g) where the unitialized memory was first allocated. This is usually at the stack allocation at the beginning of a function somewhere.
Try compiling with -Wall as well. -Wall should catch most "used uninitialized" errors at compile time.

Valgrind notifies you about use of uninitialized values - not just uninitialized values eg:
==1029== Memcheck, a memory error detector
==1029== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1029== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==1029== Command: a.out
==1029==
==1029== Conditional jump or move depends on uninitialised value(s)
==1029== at 0x4004D7: main (uninit.c:6)
==1029==
==1029==
==1029== HEAP SUMMARY:
==1029== in use at exit: 0 bytes in 0 blocks
==1029== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1029==
==1029== All heap blocks were freed -- no leaks are possible
==1029==
==1029== For counts of detected and suppressed errors, rerun with: -v
==1029== Use --track-origins=yes to see where uninitialised values come from
==1029== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
[adrian#iceweasel ~]$ cat uninit.c
#include <stdio.h>
int main(int argc, char *argv[])
{
int i;
if(i)
{
printf("Hello\n");
}
return 0;
}

Related

Valgrind complaining about uninitialized values

I have this little snippet here:
#include <string.h>
#include <stdio.h>
int main(void) {
char b[128];
strcpy(b, "four");
if(strcmp(b, "seven") == 0) {/* Line 9 */
printf("buffer 'b' contains \"%s\"\n", b);
}
else if(strcmp(b, "four") == 0) {
printf("buffer 'b' contains \"%s\"\n", b);
}
return 0;
}
If I compile it with Clang version "7.0.0-3~ubuntu0.18.04.1 (tags/RELEASE_700/final)" it is all nice and dandy even with -O3. If I do the same with Clang version "8.0.0-3~ubuntu18.04.2 (tags/RELEASE_800/final)" or later (checked version 9.0.0, too) with every optimization except -O0 Valgrind tells me
==17979== Memcheck, a memory error detector
==17979== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17979== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17979== Command: ./glibc_strcmp_x86_64_sse_4_2_bug
==17979==
==17979== Conditional jump or move depends on uninitialised value(s)
==17979== at 0x400540: main (glibc_strcmp_x86_64_sse_4_2_bug.c:9)
==17979== Uninitialised value was created by a stack allocation
==17979== at 0x400520: main (glibc_strcmp_x86_64_sse_4_2_bug.c:4)
==17979==
buffer 'b' contains "four"
==17979==
==17979== HEAP SUMMARY:
==17979== in use at exit: 0 bytes in 0 blocks
==17979== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==17979==
==17979== All heap blocks were freed -- no leaks are possible
==17979==
==17979== For counts of detected and suppressed errors, rerun with: -v
==17979== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
If I initialize the buffer with e.g.: char b[128] = {0}; it is OK, of course, no complains anymore. Or if I use a local version of strcmp.
Dumping the assembly outputs of each -O1 and -O0 respectively shows that the optimization of Clang-8 optimizes all occurrences of strcmp (and strcpy) away. Clang-7 does not do it, it calls all of the functions.
But who is to blame here? Is it a bug in Clang > 7? Or is my assumption wrong that strcmp, even if optimized away, should stop once either of the inputs reaches \0?

Flex yy_scan_string memory leaks

Description
This is an example created to introduce issue from larger solution. I have to use flex and yy_scan_string(). I have an issue with memory leaks in flex (code below). In this example memory leaks are marked as "still reachable", but in the original solution they get marked as "lost memory".
I think this problem is somewhere in memory allocated by flex internally, which I don't know how to free properly and I can't find any tutorial / documentation for that issue.
file.lex
%option noyywrap
%{
#include <stdio.h>
%}
%%
. printf("%s\n", yytext);
%%
int main() {
printf("Start\n");
yy_scan_string("ABC");
yylex();
printf("Stop\n");
return 0;
}
bash$ flex file.lex
bash$ gcc lex.yy.c
bash$ ./a.out
Start
H
a
l
l
o
W
o
r
l
d
Stop
bash$ valgrind --leak-check=full --show-leak-kinds=all ./a.out
==6351== Memcheck, a memory error detector
==6351== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6351== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==6351== Command: ./a.out
==6351==
==6351== error calling PR_SET_PTRACER, vgdb might block
Start
A
B
C
Stop
==6351==
==6351== HEAP SUMMARY:
==6351== in use at exit: 77 bytes in 3 blocks
==6351== total heap usage: 4 allocs, 1 frees, 589 bytes allocated
==6351==
==6351== 5 bytes in 1 blocks are still reachable in loss record 1 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10ABE5: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in /home/./a.out)
==6351==
==6351== 8 bytes in 1 blocks are still reachable in loss record 2 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10A991: yyensure_buffer_stack (in ./a.out)
==6351== by 0x10A38D: yy_switch_to_buffer (in ./a.out)
==6351== by 0x10AB8E: yy_scan_buffer (in ./a.out)
==6351== by 0x10AC68: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in ./a.out)
==6351==
==6351== 64 bytes in 1 blocks are still reachable in loss record 3 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10AAEF: yy_scan_buffer (in ./a.out)
==6351== by 0x10AC68: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in ./a.out)
==6351==
==6351== LEAK SUMMARY:
==6351== definitely lost: 0 bytes in 0 blocks
==6351== indirectly lost: 0 bytes in 0 blocks
==6351== possibly lost: 0 bytes in 0 blocks
==6351== still reachable: 77 bytes in 3 blocks
==6351== suppressed: 0 bytes in 0 blocks
==6351==
==6351== For counts of detected and suppressed errors, rerun with: -v
==6351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The answer is mentioned in the flex documentation, but you have to read carefully to find it. (See below.)
If you generate a reentrant scanner, then you are responsible for creating and destroying each scanner object you require, and the scanner object manages all of the memory required by a scanner instance. But even if you don't use the reentrant interface, you can use yylex_destroy to manage memory. In the traditional non-reentrant interface, then there is no scanner_t argument, so the prototype of yylex_destroy is simply
int yylex_destroy(void);
(Although it has a return value which is supposed to be a status code, it never returns an error.)
You can, if you want to, call yylex_init, which also takes no arguments in the non-reentrant interface, but unlike the reentrant interface, it is not necessary to call it.
From the manual chapter on memory management:
Flex allocates dynamic memory during initialization, and once in a while from within a call to yylex(). Initialization takes place during the first call to yylex(). Thereafter, flex may reallocate more memory if it needs to enlarge a buffer. As of version 2.5.9 Flex will clean up all memory when you call yylex_destroy See faq-memory-leak.
Example:
$ cat clean.l
%option noinput nounput noyywrap nodefault
%{
#include <stdio.h>
%}
%%
.|\n ECHO;
%%
int main() {
printf("Start\n");
yy_scan_string("ABC");
yylex();
printf("Stop\n");
yylex_destroy();
return 0;
}
$ flex -o clean.c clean.l
$ gcc -Wall -o clean clean.c
$ valgrind --leak-check=full --show-leak-kinds=all ./clean
==16187== Memcheck, a memory error detector
==16187== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16187== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16187== Command: ./clean
==16187==
Start
ABCStop
==16187==
==16187== HEAP SUMMARY:
==16187== in use at exit: 0 bytes in 0 blocks
==16187== total heap usage: 4 allocs, 4 frees, 1,101 bytes allocated
==16187==
==16187== All heap blocks were freed -- no leaks are possible
==16187==
==16187== For counts of detected and suppressed errors, rerun with: -v
==16187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

valgrind mips doesn't show stack trace

I'm using valgrind 3.13 on mips platform, however I write a test program and found valgrind didn't trace to file line number, for x86 it works fine. what could be the problem?
# valgrind --trace-children=yes --leak-check=yes --num-callers=20 /tmp/a.out
==2957== Memcheck, a memory error detector
==2957== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2957== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2957== Command: /tmp/a.out
==2957==
==2957== Invalid write of size 4
==2957== at 0x4000B90: ??? (in /lib/ld-uClibc.so.0)
==2957== by 0x4000B3C: ??? (in /lib/ld-uClibc.so.0)
==2957== Address 0x7e8bdcbc is on thread 1's stack
==2957== 4 bytes below stack pointer
==2957==
==2957== Conditional jump or move depends on uninitialised value(s)
==2957== at 0x48B4A44: ??? (in /lib/libc.so.0)
==2957== by 0x48ADBE4: ??? (in /lib/libc.so.0)
==2957==
buf=test buf
in func1:x[10]=10
/tmp/a.out: can't resolve symbol '__libc_freeres'
==2957==
==2957== HEAP SUMMARY:
==2957== in use at exit: 0 bytes in 0 blocks
==2957== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2957==
==2957== All heap blocks were freed -- no leaks are possible
==2957==
==2957== For counts of detected and suppressed errors, rerun with: -v
==2957== Use --track-origins=yes to see where uninitialised values come from
==2957== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Below is my test.c, compiled with mips toolchain with option "-g -O0"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
func1()
{
int *x=malloc(10*sizeof(int *));
x[10]=10;
printf("in func1:x[10]=%d\n", x[10]);
}
main()
{
char buf[2];
char buf2[10];
strcpy(buf,"test buf\n");
printf("buf=%s\n", buf);
func1();
}

uninitialised value(s) - if_nan function

I have a code that calls the following function
int if_nan(double a)
{
return a!=a;
}
to find if_nan() is encountered in calculations. When I do memcheck with Valgrind, I get the following error:
==3484== Conditional jump or move depends on uninitialised value(s)
==3484== at 0x804B0A9: if_nan (sph.c:71)
==3484== by 0x8051B78: pressure_forces (pressure_force.c:21)
...
I don't understand what value to be initialized here. Please suggest a way to avoid this error. Thank You
And we don't understand what you want from us by posting 1/100th of your code !!!
Howver, check the below part for your clarification. And please , from next time, try to put the entire code here. Its free of cost. :-)
Case 1
code
#include <stdio.h>
#include <stdlib.h>
int if_nan(double a)
{
return a!=a;
}
int main()
{
double p;
int result;
p = 3.5;
result = if_nan(p);
printf("\n\nresult is %d\n\n", result);
return 0;
}
O/P
[sourav#localhost ~]$ gcc -g so_test3.c -o test
[sourav#localhost ~]$ valgrind --leak-check=full ./test
==24217== Memcheck, a memory error detector
==24217== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==24217== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==24217== Command: ./test
==24217==
result is 0
==24217==
==24217== HEAP SUMMARY:
==24217== in use at exit: 0 bytes in 0 blocks
==24217== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==24217==
==24217== All heap blocks were freed -- no leaks are possible
==24217==
==24217== For counts of detected and suppressed errors, rerun with: -v
==24217== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 8)
[sourav#localhost ~]$
Case 2
Code
#include <stdio.h>
#include <stdlib.h>
int if_nan(double a)
{
return a!=a;
}
int main()
{
double p;
int result;
//p = 3.5;
result = if_nan(p);
printf("\n\nresult is %d\n\n", result);
return 0;
}
O/P
[sourav#localhost ~]$ gcc -g so_test3.c -o test
[sourav#localhost ~]$ valgrind --leak-check=full ./test
==24229== Memcheck, a memory error detector
==24229== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==24229== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==24229== Command: ./test
==24229==
==24229== Use of uninitialised value of size 4
==24229== at 0x830C3B: _itoa_word (in /lib/libc-2.5.so)
==24229== by 0x8343D0: vfprintf (in /lib/libc-2.5.so)
==24229== by 0x83BE82: printf (in /lib/libc-2.5.so)
==24229== by 0x80483DF: main (so_test3.c:17)
==24229==
==24229== Conditional jump or move depends on uninitialised value(s)
==24229== at 0x830C43: _itoa_word (in /lib/libc-2.5.so)
==24229== by 0x8343D0: vfprintf (in /lib/libc-2.5.so)
==24229== by 0x83BE82: printf (in /lib/libc-2.5.so)
==24229== by 0x80483DF: main (so_test3.c:17)
==24229==
==24229== Conditional jump or move depends on uninitialised value(s)
==24229== at 0x8327A0: vfprintf (in /lib/libc-2.5.so)
==24229== by 0x83BE82: printf (in /lib/libc-2.5.so)
==24229== by 0x80483DF: main (so_test3.c:17)
==24229==
result is 0
==24229==
==24229== HEAP SUMMARY:
==24229== in use at exit: 0 bytes in 0 blocks
==24229== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==24229==
==24229== All heap blocks were freed -- no leaks are possible
==24229==
==24229== For counts of detected and suppressed errors, rerun with: -v
==24229== Use --track-origins=yes to see where uninitialised values come from
==24229== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 12 from 8)
[sourav#localhost ~]$
Looks familiar? :-) [No hard feelings]

Valgrind not showing line numbers in spite of -g flag (on Ubuntu 11.10/VirtualBox)

I'm following 'Learn C the Hard Way', specifically the chapter on Valgrind. This chapter gives you a deliberately wrong program to show how Valgrind works.
When I run the exercise under Valgrind I do not get line numbers in my stack trace, just '(below main)' for the errors.
I am definitely compiling with the -g flag.
My Valgrind output is as follows:
djb#twin:~/projects/Learning/C$ valgrind ./ex4
==5190== Memcheck, a memory error detector
==5190== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5190== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==5190== Command: ./ex4
==5190==
==5190== Use of uninitialised value of size 4
==5190== at 0x4078B2B: _itoa_word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x4078B33: _itoa_word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407CC10: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407C742: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
I am 0 years old.
I am 68882420 inches tall.
==5190==
==5190== HEAP SUMMARY:
==5190== in use at exit: 0 bytes in 0 blocks
==5190== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5190==
==5190== All heap blocks were freed -- no leaks are possible
==5190==
==5190== For counts of detected and suppressed errors, rerun with: -v
==5190== Use --track-origins=yes to see where uninitialised values come from
==5190== ERROR SUMMARY: 22 errors from 4 contexts (suppressed: 11 from 6)
I'm using Ubuntu 11.10 in a VirtualBox VM.
Thank you for any help.
Update
It seems that if I call a function from main() and that function contains a mistake (eg an uninitialized variable), then I do get a trace to the place that function was called in main(). However errors within main() remain unspecified. See this paste for an example.
The output you provided in your question contains the following line:
==5190== Use --track-origins=yes to see where uninitialised values come from
Per this message you should run ./ex4 like this:
valgrind --track-origins=yes ./ex4
To avoid some problems with Valgrind unable to find debug information, you can use static linking:
gcc -static -g -o ex4 ex4.c
Valgrind's output will then contain messages like Uninitialised value was created by a stack allocation:
==17673== Memcheck, a memory error detector
==17673== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==17673== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==17673== Command: ./ex4
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x8048ECD: main (ex4.c:8)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EFA: bad_function (ex4.c:17)
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x80490BE: (below main) (in /home/user/ex4)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EBE: main (ex4.c:4)
...
I am -1094375076 years old.
...
I am -1094369310 inches tall.
...
==17673==
==17673== HEAP SUMMARY:
==17673== in use at exit: 0 bytes in 0 blocks
==17673== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17673==
==17673== All heap blocks were freed -- no leaks are possible
==17673==
==17673== For counts of detected and suppressed errors, rerun with: -v
==17673== ERROR SUMMARY: 83 errors from 21 contexts (suppressed: 0 from 0)
File ex4.c:
1 #include <stdio.h>
2
3 int main()
4 {
5 int age = 10;
6 int height;
7
8 bad_function();
9
10 printf("I am %d years old.\n");
11 printf("I am %d inches tall.\n", height);
12
13 return 0;
14 }
15
16 int bad_function()
17 {
18 int x;
19 printf("%d\n", x);
20 }
Valgrind's output isn't ideal. It identifies the stack frame (function) containing the uninitialized variable, but it does not print the name of the variable.
Running Linux under VirtualBox has no effect on Valgrind.
I too was compiling with the -g flag and still not getting line numbers. After removing the .dSYM directory for my app, and running valgrind with the --dsymutil=yes option, I finally got line numbers.
On many distros the default version of glibc doesn't contain debug symbols.
Try installing the libc6-dbg package.
I chased this problem and none of the other answers worked. My output displayed the correct symbols, but line numbers were not present.
In my case, it was due to the library in question using .zdebug compressed line number info, and the version of valgrind I was using was old and did not yet have the needed patch [0].
The solution was to upgrade valgrind to the latest version.
[0] https://bugs.kde.org/show_bug.cgi?id=303877
you should compile it with "-g" .
gcc -g test.c -o test
and then
valgrind --track-origins=yes --leak-check=full ./test
Note that running valgrind with the --dsymutil=yes solution es just for Mac OS X.
According to the docs:
--dsymutil=no|yes [no]
This option is only relevant when running Valgrind on Mac OS X.
Mac OS X uses a deferred debug information (debuginfo) linking scheme.
When object files containing debuginfo are linked into a .dylib or an
executable, the debuginfo is not copied into the final file. Instead,
the debuginfo must be linked manually by running dsymutil, a
system-provided utility, on the executable or .dylib. The resulting
combined debuginfo is placed in a directory alongside the executable
or .dylib, but with the extension .dSYM.
try gcc not cc
cc does not provide the line numbers, but gcc does

Resources