Mac OS X上的Valgrind错误导致printf double

Question

At the moment I am learning C with the awesome learncodethehardway series . I encountered the following:

I compile the following code and everything looks totally fine to me:

#include <stdio.h>

int main(int argc, char *argv[]) {

    int bugs = 100;
    double bug_rate = 1.2;

    printf("You have %d bugs a the imaginary rate of %f!\n", bugs, bug_rate);

    return 0;
}

It works also correctly.

When I run now Valgrind (3.11.0; should be updated for OS X El Capitan ) I get following messages:

==18896== Memcheck, a memory error detector
==18896== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18896== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==18896== Command: ./ex7
==18896==
You have 100 bugs a the imaginary rate of 1.200000!
==18896==
==18896== HEAP SUMMARY:
==18896==     in use at exit: 26,081 bytes in 188 blocks
==18896==   total heap usage: 272 allocs, 84 frees, 32,321 bytes allocated
==18896==
==18896== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 42 of 65
==18896==    at 0x100007EA1: malloc (vg_replace_malloc.c:303)
==18896==    by 0x1001C58D6: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1001C621F: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1001C2877: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1001EB3E6: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1002146C8: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1001EA389: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x1001E8223: printf (in /usr/lib/system/libsystem_c.dylib)
==18896==    by 0x100000F32: main (ex7.c:10)
==18896==
==18896== 2,064 bytes in 1 blocks are possibly lost in loss record 59 of 65
==18896==    at 0x10000821C: malloc_zone_malloc (vg_replace_malloc.c:305)
==18896==    by 0x1004F6EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA182: protocols() (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004E7C13: gc_init (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EF24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004FC132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA83C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==18896==    by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==18896==
==18896== LEAK SUMMARY:
==18896==    definitely lost: 80 bytes in 1 blocks
==18896==    indirectly lost: 68 bytes in 2 blocks
==18896==      possibly lost: 2,064 bytes in 1 blocks
==18896==    still reachable: 0 bytes in 0 blocks
==18896==         suppressed: 23,869 bytes in 184 blocks
==18896==
==18896== For counts of detected and suppressed errors, rerun with: -v
==18896== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 18 from 18)

I don't get it. There is nothing wrong with my line:10 isn't it?

THX a lot.

Answer 1

Unfortunately, the libraries that printf uses, do not always behave in an ideal way. Valgrind will notice all errors - not only the ones you made, but every error made in the standard C library implementation on OSX, for instance.

Some of those "errors" may be actual bugs (which is pretty rare), others are likely little shortcuts the library developers took, which may not look completely correct to Valgrind. One such thing is to rely on the operating system to clear and free all left over memory when a program exits - when in a pedantic world, the program should free all of its memory before exit. However, this stopped being strictly necessary somewhere around the days of DOS and AmigaOS .

I am not saying this is necessarily what you are seeing in that error, but that you need to be mindful of what Valgrind says.

To use Valgrind in practice, you may want a suppression file, which removes error messages related to system libraries. Here is a somewhat recent (January 2015) blog post about this issue which came about exactly because of "learning C the hard way" on OSX.