Valgrind uninitialized value error [duplicate] - c

Question

I'm sorry if i eventually do something wrong.
Ok my problem is the following:
I just coded something very easy, but when you take a look at the Valgrind error output it just confuses me.
Code:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
int num1 = 100;
double num2 = 1.2;
printf("Number 1 one is: %d.\n Number two is: %f.\n", num1, num2);
return 0;
}
Valgrind error report:
$ valgrind --leak-check=full ./yaq
==50642== Memcheck, a memory error detector
==50642== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==50642== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==50642== Command: ./yaq
==50642==
--50642-- ./yaq:
--50642-- dSYM directory has wrong UUID; consider using --dsymutil=yes
==50642== Conditional jump or move depends on uninitialised value(s)
==50642== at 0x1003FCC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==50642== by 0x1001F0B96: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001FAFE5: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1002209AE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x100220C80: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001F6B71: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001F49D7: printf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x100000F32: main (in ./yaq)
==50642==
Number 1 one is: 100.
Number two is: 1.200000.
==50642==
==50642== HEAP SUMMARY:
==50642== in use at exit: 38,673 bytes in 427 blocks
==50642== total heap usage: 510 allocs, 83 frees, 44,945 bytes.
==50642== To see them, rerun with: --leak-check=full --show-leak- kinds=all
==50642==
==50642== For counts of detected and suppressed errors, rerun with: -v
==50642== Use --track-origins=yes to see where uninitialised values come from
==50642== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 17 from 17)
Why does it say 3 errors ?
Thanks in advance.
Best regards

Answer 1

You may be able to see them if you run with --show-leak-kinds=all:
==96034== Memcheck, a memory error detector
==96034== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==96034== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==96034== Command: ./yaq
==96034==
--96034-- ./yaq:
--96034-- dSYM directory is missing; consider using --dsymutil=yes
==96034== Conditional jump or move depends on uninitialised value(s)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== 80 bytes in 1 blocks are still reachable in loss record 48 of 85
==96034== at 0x10000859B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==96034== by 0x1001D1756: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001D2075: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001CE88B: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F6D72: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== 4,096 bytes in 1 blocks are still reachable in loss record 85 of 85
==96034== at 0x10000859B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==96034== by 0x1001F0856: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1002053A7: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021F77D: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== LEAK SUMMARY:
==96034== definitely lost: 0 bytes in 0 blocks
==96034== indirectly lost: 0 bytes in 0 blocks
==96034== possibly lost: 0 bytes in 0 blocks
==96034== still reachable: 4,244 bytes in 4 blocks
==96034== suppressed: 34,783 bytes in 425 blocks
==96034==
==96034== For counts of detected and suppressed errors, rerun with: -v
==96034== Use --track-origins=yes to see where uninitialised values come from
==96034== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 18 from 18)
Those are issues in the OS X system libraries. I suppressed them by generating this suppressions file with valgrind --leak-check=yes --show-leak-kinds=all --gen-suppressions=yes ./yaq. The output is a bit cleaner then:
$ valgrind --leak-check=yes --show-leak-kinds=all --suppressions=yaq.supp ./yaq [7:47:49]
==96285== Memcheck, a memory error detector
==96285== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==96285== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==96285== Command: ./yaq
==96285==
--96285-- ./yaq:
--96285-- dSYM directory is missing; consider using --dsymutil=yes
Number 1 one is: 100.
Number two is: 1.200000.
==96285==
==96285== HEAP SUMMARY:
==96285== in use at exit: 39,027 bytes in 429 blocks
==96285== total heap usage: 510 allocs, 81 frees, 45,171 bytes allocated
==96285==
==96285== LEAK SUMMARY:
==96285== definitely lost: 0 bytes in 0 blocks
==96285== indirectly lost: 0 bytes in 0 blocks
==96285== possibly lost: 0 bytes in 0 blocks
==96285== still reachable: 0 bytes in 0 blocks
==96285== suppressed: 39,027 bytes in 429 blocks
==96285==
==96285== For counts of detected and suppressed errors, rerun with: -v
==96285== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 19)

Answer 2

Valgrind support on OS X is currently being actively worked on. Your best approach is to ensure you are using a SVN trunk build, and update frequently.
The errors Valgrind is reporting to you are present within the OS X system libraries. These are not the fault of your program, but because even simple programs including these system libraries Valgrind continues to pick them up. Suppressions within Valgrind trunk are continually being updated to catch these issues, allowing you to focus on the real problems that may be present within your code.
The following commands will allow you to use Valgrind trunk, if you're not already:
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure
make -j4
sudo make install