uninitialised value(s) - if_nan function - c

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]

Related

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();
}

wchar_t valgrind issue - Invalid read of size 8

I'm not able to figure out why Valgrind is printing Invalid read of size 8 when using wchar_t. I'm running a 64bit Ubuntu (3.5.0-25) system with valgrind-3.7.0 and gcc 4.7.2.
#include <stdio.h>
#include <wchar.h>
#include <stdlib.h>
#include <string.h>
int main()
{
// const wchar_t *text = L"This is a t"; // no Valgrind error
// const wchar_t *text = L"This is a teeeeeeee"; // no Valgrind error
const wchar_t *text = L"This is a test"; // Valgrind ERRROR
wchar_t *new_text = NULL;
new_text = (wchar_t*) malloc( (wcslen(text) + 1) * sizeof(wchar_t));
wcsncpy(new_text, text, wcslen(text));
new_text[wcslen(text)] = L'\0';
printf("new_text: %ls\n", new_text);
free(new_text);
return 0;
}
Compile:
$ gcc -g -std=c99 test.c -o test
$ valgrind --tool=memcheck --leak-check=full --track-origins=yes --show-reachable=yes ./test
Valgrind results:
==19495== Memcheck, a memory error detector
==19495== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==19495== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==19495== Command: ./test
==19495==
==19495== Invalid read of size 8
==19495== at 0x4ED45A7: wcslen (wcslen.S:55)
==19495== by 0x4ED5C0E: wcsrtombs (wcsrtombs.c:74)
==19495== by 0x4E7D160: vfprintf (vfprintf.c:1630)
==19495== by 0x4E858D8: printf (printf.c:35)
==19495== by 0x4006CC: main (test.c:16)
==19495== Address 0x51f1078 is 56 bytes inside a block of size 60 alloc'd
==19495== at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19495== by 0x40066F: main (test.c:12)
==19495==
new_text: This is a test
==19495==
==19495== HEAP SUMMARY:
==19495== in use at exit: 0 bytes in 0 blocks
==19495== total heap usage: 1 allocs, 1 frees, 60 bytes allocated
==19495==
==19495== All heap blocks were freed -- no leaks are possible
==19495==
==19495== For counts of detected and suppressed errors, rerun with: -v
==19495== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Now if I run the same but with a 'working string', let's say
const wchar_t *text = L"This is a t"; // no Valgrind error
// const wchar_t *text = L"This is a teeeeeeee"; // no Valgrind error
// const wchar_t *text = L"This is a test"; // Valgrind ERRROR
I get no issue:
==19571== Memcheck, a memory error detector
==19571== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==19571== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==19571== Command: ./test
==19571==
new_text: This is a t
==19571==
==19571== HEAP SUMMARY:
==19571== in use at exit: 0 bytes in 0 blocks
==19571== total heap usage: 1 allocs, 1 frees, 48 bytes allocated
==19571==
==19571== All heap blocks were freed -- no leaks are possible
==19571==
==19571== For counts of detected and suppressed errors, rerun with: -v
==19571== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
At first I thought the string size should be always be multiple of 8 (maybe some wcs read chunks of 8) but some cases failed, then I thought I'd have to append always 8 bytes for the NULL terminator ((wcslen(item) + 2) * sizeof(wchar_t)), it worked but that doesn't make any sense since sizeof(wchar_t) - in my system - is 4 bytes and should be enough to handle the L'\0' terminator.
I also read the glibc wcslen source code but nothing new. I'm now thinking of Valgrind issue. Do you guys could throw some light here? Does it worth to file a bug against Valgrind?
Thank you
This is probably caused by SSE optimisation of the wcslen function; see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=798968 or https://bugs.archlinux.org/task/30643.
When optimising wcslen, it's faster to read multiple wide characters at a time and use vectorised instructions (SSE) to compare them to L'\0'. Unfortunately valgrind sees this as an uninitialised read - which it is, but it's harmless because the result of wcslen does not depend on the uninitialised value.
The fix is to update valgrind in the hope that a newer version will suppress the false positive.

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

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;
}

strcpy valgrind invalid read of size [duplicate]

The code is here:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
char* buf = malloc(3);
strcpy(buf, "hi");
printf("%s\n", buf);
free(buf);
}
It's compiled with:
gcc a.c && valgrind ./a.out
The error message is here:
==1421== Memcheck, a memory error detector
==1421== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1421== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==1421== Command: ./a.out
==1421==
==1421== Invalid read of size 8
==1421== at 0x4EA96C1: ??? (in /lib/libc-2.14.1.so)
==1421== by 0x4E92D3B: puts (in /lib/libc-2.14.1.so)
==1421== by 0x4005BB: main (in /home/peter/a.out)
==1421== Address 0x51b4040 is 0 bytes inside a block of size 3 alloc'd
==1421== at 0x4C2740D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1421== by 0x400595: main (in /home/peter/a.out)
==1421==
hi
==1421==
==1421== HEAP SUMMARY:
==1421== in use at exit: 0 bytes in 0 blocks
==1421== total heap usage: 1 allocs, 1 frees, 3 bytes allocated
==1421==
==1421== All heap blocks were freed -- no leaks are possible
==1421==
==1421== For counts of detected and suppressed errors, rerun with: -v
==1421== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 6 from 6)
It is also very strange that valgrind reports no more errors if I use the following (just one more space):
printf("%s \n", buf);
Would anyone please help me?
This is a bug, but not reproducible on all machines.
On some machines, gcc optimizes simple printf() with, for example, puts(), which could possibly involve invalid read (or just valgrind thinks so).
If it really matters, you can 'complicate' the printf format. A space between %s and \n would do.
Here is a similar bug: C strings, strlen and Valgrind
This answer combines comments in the discussion. Thank you all!
I've run it in my own machine, and I get no errors:
==61755== Memcheck, a memory error detector
==61755== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==61755== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==61755== Command: ./a.out
==61755==
hi
==61755==
==61755== HEAP SUMMARY:
==61755== in use at exit: 0 bytes in 0 blocks
==61755== total heap usage: 1 allocs, 1 frees, 3 bytes allocated
==61755==
==61755== All heap blocks were freed -- no leaks are possible
==61755==
==61755== For counts of detected and suppressed errors, rerun with: -v
==61755== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

The valgrind reports error when printing allocated strings

The code is here:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
char* buf = malloc(3);
strcpy(buf, "hi");
printf("%s\n", buf);
free(buf);
}
It's compiled with:
gcc a.c && valgrind ./a.out
The error message is here:
==1421== Memcheck, a memory error detector
==1421== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1421== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==1421== Command: ./a.out
==1421==
==1421== Invalid read of size 8
==1421== at 0x4EA96C1: ??? (in /lib/libc-2.14.1.so)
==1421== by 0x4E92D3B: puts (in /lib/libc-2.14.1.so)
==1421== by 0x4005BB: main (in /home/peter/a.out)
==1421== Address 0x51b4040 is 0 bytes inside a block of size 3 alloc'd
==1421== at 0x4C2740D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1421== by 0x400595: main (in /home/peter/a.out)
==1421==
hi
==1421==
==1421== HEAP SUMMARY:
==1421== in use at exit: 0 bytes in 0 blocks
==1421== total heap usage: 1 allocs, 1 frees, 3 bytes allocated
==1421==
==1421== All heap blocks were freed -- no leaks are possible
==1421==
==1421== For counts of detected and suppressed errors, rerun with: -v
==1421== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 6 from 6)
It is also very strange that valgrind reports no more errors if I use the following (just one more space):
printf("%s \n", buf);
Would anyone please help me?
This is a bug, but not reproducible on all machines.
On some machines, gcc optimizes simple printf() with, for example, puts(), which could possibly involve invalid read (or just valgrind thinks so).
If it really matters, you can 'complicate' the printf format. A space between %s and \n would do.
Here is a similar bug: C strings, strlen and Valgrind
This answer combines comments in the discussion. Thank you all!
I've run it in my own machine, and I get no errors:
==61755== Memcheck, a memory error detector
==61755== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==61755== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==61755== Command: ./a.out
==61755==
hi
==61755==
==61755== HEAP SUMMARY:
==61755== in use at exit: 0 bytes in 0 blocks
==61755== total heap usage: 1 allocs, 1 frees, 3 bytes allocated
==61755==
==61755== All heap blocks were freed -- no leaks are possible
==61755==
==61755== For counts of detected and suppressed errors, rerun with: -v
==61755== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

Resources