I develop a very small garbage collector in C and doesn't matter how many malloc()s I did it always suppressed 4096 bytes in 1 block (1 free() missed) git clone https://github.com/mazoti/cgc cd cgc clang -g example.c valgrind ./a.out I tested exact the same code in debian linux and everything is fine (no leaks). I don't know if it is a libc, kernel or valgrind bug. Best regards,
There is no problem here. If you run Valgrind with -s you will get --4534-- used_suppression: 1 MEMCHECK-LIBC-REACHABLE /usr/local/libexec/valgrind/default.supp:589 suppressed: 4,096 bytes in 1 blocks That means that the 4k still in use is known and suppressed by the system suppressions file If you run Valgrind with --defaut-suppressions=no then you will see ==4537== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1 ==4537== at 0x484C8A4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==4537== by 0x4974AA3: ??? (in /lib/libc.so.7) ==4537== by 0x4987278: ??? (in /lib/libc.so.7) ==4537== by 0x497B012: ??? (in /lib/libc.so.7) ==4537== by 0x497AD89: vfprintf_l (in /lib/libc.so.7) ==4537== by 0x4975AF3: printf (in /lib/libc.so.7) ==4537== by 0x201D48: main (example.c:16) In theory it would be possible to remove this suppression by modifying libc. On Linux, GNU libc has a __libc_freeres function, In normal use, Linux GNU libc applications do not call this function. Valgrind does some fiddling on guest application termination and _does_ call thisa function. The advantages of using freeres over suppressions are that a) it is slighlty cleaner b) it is less sensitive (suppressions tend to change over time and libc could add more uses of reachable memory). If this really bothers you, open a bugzilla item for libc to add a freeres function and then I can add that to Valgrind.