I have following valgrind output:
==28099==
==28099== HEAP SUMMARY:
==28099== in use at exit: 0 bytes in 0 blocks
==28099== total heap usage: 131 allocs, 131 frees, 3,472 bytes allocated
==28099==
==28099== All heap blocks were freed -- no leaks are possible
==28099==
==28099== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--28099--
--28099-- used_suppression: 2 dl-hack3-cond-1
--28099-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
==28099==
==28099== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
There are 4 suppressed error. Although there is no leak here, but creats problem while porting to another system.
[EDIT]
I rerun with the valgrind -v option too. But I don't find any errors there.
==30287== Memcheck, a memory error detector
==30287== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==30287== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==30287== Command: ./EXECUTABLE1 test_input.txt
==30287==
--30287-- Valgrind options:
--30287-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--30287-- -v
--30287-- --gen-suppressions=all
--30287-- --error-limit=no
--30287-- Contents of /proc/version:
--30287-- Linux version 2.6.38.3.2.amd64-smp (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Wed Apr 20 17:36:19 CEST 2011
--30287-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--30287-- Page sizes: currently 4096, max supported 4096
--30287-- Valgrind library directory: /usr/lib/valgrind
--30287-- Reading syms from /home/path/to/file(0x400000)
--30287-- Reading syms from /lib/ld-2.11.2.so (0x4000000)
--30287-- Considering /lib/ld-2.11.2.so ..
--30287-- .. CRC mismatch (computed cd91cee9 wanted 11b4673c)
--30287-- Considering /usr/lib/debug/lib/ld-2.11.2.so ..
--30287-- .. CRC is valid
--30287-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux (0x38000000)
--30287-- object doesn't have a dynamic symbol table
--30287-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp
--30287-- Reading suppressions file: /usr/lib/valgrind/default.supp
--30287-- REDIR: 0x4016230 (strlen) redirected to 0x380408a7 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--30287-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so (0x4a20000)
--30287-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4c21000)
==30287== WARNING: new redirection conflicts with existing -- ignoring it
--30287-- new: 0x04016230 (strlen ) R-> 0x04c25850 strlen
--30287-- REDIR: 0x40160a0 (index) redirected to 0x4c25460 (index)
--30287-- REDIR: 0x4016120 (strcmp) redirected to 0x4c25e30 (strcmp)
--30287-- Reading syms from /lib/libm-2.11.2.so (0x4e29000)
--30287-- Considering /lib/libm-2.11.2.so ..
--30287-- .. CRC mismatch (computed dd5c85df wanted ccd85fcf)
--30287-- Considering /usr/lib/debug/lib/libm-2.11.2.so ..
--30287-- .. CRC is valid
--30287-- Reading syms from /lib/libc-2.11.2.so (0x50ab000)
--30287-- Considering /lib/libc-2.11.2.so ..
--30287-- .. CRC mismatch (computed 7d8e8f4f wanted 9b015f2c)
--30287-- Considering /usr/lib/debug/lib/libc-2.11.2.so ..
--30287-- .. CRC is valid
--30287-- REDIR: 0x5128600 (__GI_strrchr) redirected to 0x4c25280 (__GI_strrchr)
--30287-- REDIR: 0x51218c0 (malloc) redirected to 0x4c24466 (malloc)
--30287-- REDIR: 0x5128d00 (memchr) redirected to 0x4c25ed0 (memchr)
--30287-- REDIR: 0x512a750 (memcpy) redirected to 0x4c25f00 (memcpy)
--30287-- REDIR: 0x5126b10 (strlen) redirected to 0x4a205ac (_vgnU_ifunc_wrapper)
==30287== WARNING: new redirection conflicts with existing -- ignoring it
--30287-- new: 0x05126b40 (__GI_strlen ) R-> 0x04c257f0 strlen
--30287-- REDIR: 0x5126b40 (__GI_strlen) redirected to 0x4c25810 (__GI_strlen)
--30287-- REDIR: 0x512baf0 (__GI___rawmemchr) redirected to 0x4c26ba0 (__GI___rawmemchr)
--30287-- REDIR: 0x51217e0 (free) redirected to 0x4c24076 (free)
Following are the keys and their corresponding value present
--30287-- REDIR: 0x512bb40 (strchrnul) redirected to 0x4c26b50 (strchrnul)
You can view / modify the suppressed errors in /usr/lib/valgrind/default.supp.
The suppressed errors are just errors that are system specific, known problems with your libraries. So they are not the right suspects for portability problems to another system.
On x86 hosts valgrind outputs such line:
For counts of detected and suppressed errors, rerun with: -v
So run your prog like this: valgrind -v ./myprog.
Related
I want to use valgrind to see if my program has memory errors.
I want to run the program on Alpine linux which has different standard c library (musl vs glibc).
Here is and example output on "echo" command with valgrind on the Alpine linux:
/ # valgrind echo "hi"
==480== Memcheck, a memory error detector
==480== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==480== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==480== Command: echo hi
==480==
hi
==480==
==480== HEAP SUMMARY:
==480== in use at exit: 0 bytes in 0 blocks
==480== total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==480==
==480== All heap blocks were freed -- no leaks are possible
==480==
==480== For lists of detected and suppressed errors, rerun with: -s
==480== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As expected there are no problems in "echo" program.
When I run my program with valgrind on Alpine (passing--track-origins=yes, --leak-check=full doesn't cause any change):
/ # valgrind work/test_lib
==481== Memcheck, a memory error detector
==481== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==481== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==481== Command: work/test_lib
==481==
Please pass path to lib + config + (optional data_json) (optional output path)
/ #
The summary is missing. I don't see any errors. The program itself is very simple - just prints the lines after checking the program didn't receive 2 input parameters. Also when I run the program with arguments, it runs correctly and prints the right output result. There is no valgrind summary output after program ends in both cases.
In the other machine (Centos) valgrind indeed print valgrind summary output in the end (which is clean of problems).
The program was complied with gcc-4.8 and glibc, but without any special dependencies:
g++ -Wall --std=c++11 -ldl -march=x86-64 -msse2 -msse3 -msse4 test_lib.cpp -o test_lib
/ # ldd work/test_lib
/lib64/ld-linux-x86-64.so.2 (0x7fc52c31b000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fc52c31b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fc52c0cd000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fc52c31b000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fc52c0af000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fc52c31b000)
I was expecting to see valgrind summary report after running my program with valgrind on Alpine linux.
OK,
The code that is being executed is:
if (argc <= 2) { printf("Please pass path to lib + ...\n"); return -1; }
I don't see a reason to add "--trace-children=yes" to cause valgrind to work in this case.
But Alpine (since it was compiled with glibc) causes this to create a child process. Adding "--trace-children=yes" solves the problem in Alpine for programs that were compiled with glibc.
I tried to track the "child" process using ps -ef | more
valgrind --trace-children=yes /lib/ld-musl-x86_64.so.1 --argv0
./test_lib --preload /lib/libgcompat.so.0
/usr/libexec/valgrind/vgpreload_core-amd64-linux.so:/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
-- /work/test_lib
when running "valgrind echo hi", I don't see all those "--preload"
main.c as only ...
int main(void)
{
return 0;
}
Executing ...
gcc `pkg-config --cflags --libs glib-2.0` -W -Wall -Wextra main.c -o out
Compiles into an executable ...
out
Executing ...
valgrind --show-leak-kinds=all --leak-check=full -v ./out
Gives me ...
==6404== Memcheck, a memory error detector
==6404== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6404== Using Valgrind-3.14.0-3a3000290b-20181009X and LibVEX; rerun with -h for copyright info
==6404== Command: ./out
==6404==
--6404-- Valgrind options:
--6404-- --show-leak-kinds=all
--6404-- --leak-check=full
--6404-- -v
--6404-- Contents of /proc/version:
--6404-- Linux version 4.19.28-1-MANJARO (builduser#development) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Sun Mar 10 08:32:42 UTC 2019
--6404--
--6404-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--6404-- Page sizes: currently 4096, max supported 4096
--6404-- Valgrind library directory: /usr/lib/valgrind
--6404-- Reading syms from /home/killbyte/Documents/Curso/LI3/tester-project-li3/out
--6404-- Reading syms from /usr/lib/ld-2.28.so
--6404-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--6404-- object doesn't have a dynamic symbol table
--6404-- Scheduler: using generic scheduler lock implementation.
--6404-- Reading suppressions file: /usr/lib/valgrind/default.supp
==6404== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-6404-by-killbyte-on-???
==6404== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-6404-by-killbyte-on-???
==6404== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-6404-by-killbyte-on-???
==6404==
==6404== TO CONTROL THIS PROCESS USING vgdb (which you probably
==6404== don't want to do, unless you know exactly what you're doing,
==6404== or are doing some strange experiment):
==6404== /usr/lib/valgrind/../../bin/vgdb --pid=6404 ...command...
==6404==
==6404== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==6404== /path/to/gdb ./out
==6404== and then give GDB the following command
==6404== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=6404
==6404== --pid is optional if only one valgrind process is running
==6404==
--6404-- REDIR: 0x401ff20 (ld-linux-x86-64.so.2:strlen) redirected to 0x580c9742 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--6404-- REDIR: 0x401fcf0 (ld-linux-x86-64.so.2:index) redirected to 0x580c975c (vgPlain_amd64_linux_REDIR_FOR_index)
--6404-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--6404-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
==6404== WARNING: new redirection conflicts with existing -- ignoring it
--6404-- old: 0x0401ff20 (strlen ) R-> (0000.0) 0x580c9742 vgPlain_amd64_linux_REDIR_FOR_strlen
--6404-- new: 0x0401ff20 (strlen ) R-> (2007.0) 0x0483ad80 strlen
--6404-- REDIR: 0x401c700 (ld-linux-x86-64.so.2:strcmp) redirected to 0x483be40 (strcmp)
--6404-- REDIR: 0x4020480 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x483f860 (mempcpy)
--6404-- Reading syms from /usr/lib/libglib-2.0.so.0.5800.3
--6404-- object doesn't have a symbol table
--6404-- Reading syms from /usr/lib/libc-2.28.so
--6404-- Reading syms from /usr/lib/libpthread-2.28.so
--6404-- Reading syms from /usr/lib/libpcre.so.1.2.11
--6404-- object doesn't have a symbol table
--6404-- REDIR: 0x4a23060 (libc.so.6:strchrnul) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a3b800 (libc.so.6:wcslen) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a27b10 (libc.so.6:memrchr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a3cf90 (libc.so.6:wcsnlen) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21b70 (libc.so.6:memcpy##GLIBC_2.14) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21a20 (libc.so.6:strncasecmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a216c0 (libc.so.6:memmove) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
==6404== Preferring higher priority redirection:
--6404-- old: 0x04af6c60 (__memcpy_avx_unalign) R-> (2018.0) 0x0483c300 memcpy##GLIBC_2.14
--6404-- new: 0x04af6c60 (__memcpy_avx_unalign) R-> (2018.1) 0x0483e8a0 memmove
--6404-- REDIR: 0x4a20840 (libc.so.6:strncpy) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a219d0 (libc.so.6:strcasecmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20210 (libc.so.6:strcat) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20880 (libc.so.6:rindex) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a23030 (libc.so.6:rawmemchr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a3bca0 (libc.so.6:wmemchr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a3b700 (libc.so.6:wcscmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21830 (libc.so.6:mempcpy) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21650 (libc.so.6:bcmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a207e0 (libc.so.6:strncmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20290 (libc.so.6:strcmp) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21790 (libc.so.6:memset) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a3b6d0 (libc.so.6:wcschr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20770 (libc.so.6:strnlen) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20340 (libc.so.6:strcspn) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20300 (libc.so.6:strcpy) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a208b0 (libc.so.6:strpbrk) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20250 (libc.so.6:index) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20740 (libc.so.6:strlen) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21a70 (libc.so.6:strcasecmp_l) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21620 (libc.so.6:memchr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a20b70 (libc.so.6:strspn) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21990 (libc.so.6:stpncpy) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21950 (libc.so.6:stpcpy) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21ac0 (libc.so.6:strncasecmp_l) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4aa1380 (libc.so.6:__memcpy_chk) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4a21540 (libc.so.6:strstr) redirected to 0x482d1c0 (_vgnU_ifunc_wrapper)
--6404-- REDIR: 0x4af6530 (libc.so.6:__strrchr_avx2) redirected to 0x483a790 (rindex)
--6404-- REDIR: 0x4af6700 (libc.so.6:__strlen_avx2) redirected to 0x483ac60 (strlen)
--6404-- REDIR: 0x4a1c8d0 (libc.so.6:malloc) redirected to 0x4837710 (malloc)
--6404-- REDIR: 0x4a1d6b0 (libc.so.6:calloc) redirected to 0x4839ab0 (calloc)
--6404-- REDIR: 0x4a1cf20 (libc.so.6:free) redirected to 0x4838940 (free)
==6404==
==6404== HEAP SUMMARY:
==6404== in use at exit: 18,604 bytes in 6 blocks
==6404== total heap usage: 6 allocs, 0 frees, 18,604 bytes allocated
==6404==
==6404== Searching for pointers to 6 not-freed blocks
==6404== Checked 101,040 bytes
==6404==
==6404== 4 bytes in 1 blocks are still reachable in loss record 1 of 6
==6404== at 0x483777F: malloc (vg_replace_malloc.c:299)
==6404== by 0x488F5C3: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x488F6BB: g_private_get (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48B906D: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48F4CDE: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE533: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== 32 bytes in 1 blocks are still reachable in loss record 2 of 6
==6404== at 0x4839B65: calloc (vg_replace_malloc.c:752)
==6404== by 0x48D8839: g_malloc0 (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48F4D47: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE533: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== 64 bytes in 1 blocks are still reachable in loss record 3 of 6
==6404== at 0x4839B65: calloc (vg_replace_malloc.c:752)
==6404== by 0x48D8839: g_malloc0 (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48F4D31: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE533: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== 88 bytes in 1 blocks are still reachable in loss record 4 of 6
==6404== at 0x483777F: malloc (vg_replace_malloc.c:299)
==6404== by 0x48D88D1: g_malloc (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48B9094: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48F4CDE: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE533: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== 2,032 bytes in 1 blocks are still reachable in loss record 5 of 6
==6404== at 0x4839B65: calloc (vg_replace_malloc.c:752)
==6404== by 0x48D8839: g_malloc0 (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48B92EE: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48F4CDE: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE533: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== 16,384 bytes in 1 blocks are still reachable in loss record 6 of 6
==6404== at 0x483777F: malloc (vg_replace_malloc.c:299)
==6404== by 0x48D88D1: g_malloc (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x48CE545: ??? (in /usr/lib/libglib-2.0.so.0.5800.3)
==6404== by 0x4010549: call_init.part.0 (in /usr/lib/ld-2.28.so)
==6404== by 0x4010649: _dl_init (in /usr/lib/ld-2.28.so)
==6404== by 0x4002039: ??? (in /usr/lib/ld-2.28.so)
==6404==
==6404== LEAK SUMMARY:
==6404== definitely lost: 0 bytes in 0 blocks
==6404== indirectly lost: 0 bytes in 0 blocks
==6404== possibly lost: 0 bytes in 0 blocks
==6404== still reachable: 18,604 bytes in 6 blocks
==6404== suppressed: 0 bytes in 0 blocks
==6404==
==6404== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==6404== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The problem is that valgrind tells me in leak summary still reachable: 18,604 bytes in 6 blocks
And i don't even have any code ... Not even the #include
As Ctx said in a comment, these allocations are done in a library constructor function for GLib, which is called automatically before your main() function is entered. They are done once in the process’ lifetime to allocate various internal structures and caches.
If you use the glib.supp suppression file installed by GLib in /usr/share/glib-2.0/valgrind/glib.supp, they should be suppressed. If any of them aren’t, please file a bug against GLib.
My valgrind for some reason doesn't happen to print the line number and the file the error happens at. This happens in a Linux Ubuntu 16.04.4 distro.
Here is how I have tested it:
/tmp/a.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char **argv)
{
char *buf = malloc(10);
strcpy(buf, argv[1]);
return 0;
}
I executed it all with the following command: cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello
$ cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello ./hello
==23422== Memcheck, a memory error detector
==23422== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23422== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23422== Command: ./hello
==23422==
==23422== Invalid read of size 1
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23422==
==23422==
==23422== Process terminating with default action of signal 11 (SIGSEGV)
==23422== Access not within mapped region at address 0x0
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== If you believe this happened as a result of a stack
==23422== overflow in your program's main thread (unlikely but
==23422== possible), you can try to increase the size of the
==23422== main thread stack using the --main-stacksize= flag.
==23422== The main thread stack size used in this run was 8388608.
==23422==
==23422== HEAP SUMMARY:
==23422== in use at exit: 10 bytes in 1 blocks
==23422== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==23422==
==23422== LEAK SUMMARY:
==23422== definitely lost: 0 bytes in 0 blocks
==23422== indirectly lost: 0 bytes in 0 blocks
==23422== possibly lost: 0 bytes in 0 blocks
==23422== still reachable: 10 bytes in 1 blocks
==23422== suppressed: 0 bytes in 0 blocks
==23422== Rerun with --leak-check=full to see details of leaked memory
==23422==
==23422== For counts of detected and suppressed errors, rerun with: -v
==23422== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
GCC Version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
Valgrind Version: valgrind-3.11.0
I also tried downloading and compiling the latest valgrind version (valgrind-3.13.0) but ended with the same issue.
EDIT:
Output with full logs:
$ valgrind -v --leak-check=full /tmp/a.out
==17717== Memcheck, a memory error detector
==17717== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17717== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17717== Command: /tmp/a.out
==17717==
--17717-- Valgrind options:
--17717-- -v
--17717-- --leak-check=full
--17717-- Contents of /proc/version:
--17717-- Linux version 4.4.0-119-generic (buildd#lcy01-amd64-013) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) ) #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018
--17717--
--17717-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--17717-- Page sizes: currently 4096, max supported 4096
--17717-- Valgrind library directory: /usr/lib/valgrind
--17717-- Reading syms from /tmp/a.out
--17717-- ELF section outside all mapped regions
--17717-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC mismatch (computed aa979a42 wanted 9019bbb7)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC is valid
--17717-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--17717-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--17717-- .. CRC mismatch (computed eea41ea9 wanted 2009db78)
--17717-- object doesn't have a symbol table
--17717-- object doesn't have a dynamic symbol table
--17717-- Scheduler: using generic scheduler lock implementation.
--17717-- Reading suppressions file: /usr/lib/valgrind/default.supp
==17717== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-17717-by-rajiska-on-???
==17717== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-17717-by-rajiska-on-???
==17717== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-17717-by-rajiska-on-???
==17717==
==17717== TO CONTROL THIS PROCESS USING vgdb (which you probably
==17717== don't want to do, unless you know exactly what you're doing,
==17717== or are doing some strange experiment):
==17717== /usr/lib/valgrind/../../bin/vgdb --pid=17717 ...command...
==17717==
==17717== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==17717== /path/to/gdb /tmp/a.out
==17717== and then give GDB the following command
==17717== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=17717
==17717== --pid is optional if only one valgrind process is running
==17717==
--17717-- REDIR: 0x401cfd0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 2567ccf6 wanted 49420590)
--17717-- object doesn't have a symbol table
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 0e27c9a8 wanted ac585421)
--17717-- object doesn't have a symbol table
==17717== WARNING: new redirection conflicts with existing -- ignoring it
--17717-- old: 0x0401cfd0 (strlen ) R-> (0000.0) 0x3809e181 ???
--17717-- new: 0x0401cfd0 (strlen ) R-> (2007.0) 0x04c31020 strlen
--17717-- REDIR: 0x401b920 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--17717-- REDIR: 0x401bb40 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--17717-- REDIR: 0x401dd30 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--17717-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC mismatch (computed 7a8ee3e4 wanted a5190ac4)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC is valid
--17717-- REDIR: 0x4ec9a00 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec5280 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ecbcf0 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec76f0 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7a80 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec914b (libc.so.6:memcpy#GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7400 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
--17717-- REDIR: 0x4ebe130 (libc.so.6:malloc) redirected to 0x4c2db20 (malloc)
--17717-- REDIR: 0x4ec5160 (libc.so.6:strcpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4edf9d0 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c31040 (strcpy)
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717==
==17717== Process terminating with default action of signal 11 (SIGSEGV)
==17717== Access not within mapped region at address 0x0
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== If you believe this happened as a result of a stack
==17717== overflow in your program's main thread (unlikely but
==17717== possible), you can try to increase the size of the
==17717== main thread stack using the --main-stacksize= flag.
==17717== The main thread stack size used in this run was 8388608.
--17717-- REDIR: 0x4ebe4f0 (libc.so.6:free) redirected to 0x4c2ed80 (free)
==17717==
==17717== HEAP SUMMARY:
==17717== in use at exit: 10 bytes in 1 blocks
==17717== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==17717==
==17717== Searching for pointers to 1 not-freed blocks
==17717== Checked 62,704 bytes
==17717==
==17717== LEAK SUMMARY:
==17717== definitely lost: 0 bytes in 0 blocks
==17717== indirectly lost: 0 bytes in 0 blocks
==17717== possibly lost: 0 bytes in 0 blocks
==17717== still reachable: 10 bytes in 1 blocks
==17717== suppressed: 0 bytes in 0 blocks
==17717== Reachable blocks (those to which a pointer was found) are not shown.
==17717== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==17717==
==17717== 1 errors in context 1 of 1:
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
EDIT 2: After testing a binary compiled on my system under a Docker system, it appears the issue is the same which leads to think the problem is on the binary itself. Compiling with the GCC of the Docker system works fine with valgrind.
EDIT 3: Just compiled the latest GCC version (8.1.0) and tried compiling the program with it: same issue. Furthermore you may want to note that valgrind can't resolve the function the issue happens in, even though the executable is not striped.
Also, in the valgrind -v command, we can see the note ELF section outside all mapped regions while reading the symbols of the executable.
I'm kinda lost there, it looks like it doesn't come from either GCC or Valgrind. Maybe some kind of system configuration ?
I use RedHat6 and valgrind 3.9.0.
I have tested the following compilers. With all compiler I used the debug flag -g
clang 4.0
==8862== Invalid read of size 1
==8862== at 0x4A09097: strcpy (in /opt/rh/devtoolset-2/root/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8862== by 0x400566: main (valg.c:10)
==8862== Address 0x0 is not stack'd, malloc'd or (recently) free'd
intel icc 15.0.3
==8250== Invalid read of size 1
==8250== at 0x4A09097: strcpy (in /opt/rh/devtoolset-2/root/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8250== by 0x4005D2: main (valg.c:10)
==8250== Address 0x0 is not stack'd, malloc'd or (recently) free'd
gcc 4.8.2
==8862== Invalid read of size 1
==8862== at 0x4A09097: strcpy (in /opt/rh/devtoolset-2/root/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8862== by 0x400566: main (valg.c:10)
==8862== Address 0x0 is not stack'd, malloc'd or (recently) free'd
All of them show the correct Invalid read of size 1.
A proper signal 11 is thrown, when executing the program.
It is not important, if you use -v or --leak-check=full.
I know that this is not an answer, but it was too long for a comment.
Problem Fixed
After testing the compilation with a different user, valgrind was able to detect the lines and functions the issues were appearing at. It took me no long after to figure out the issue came from my ~/.profile file where I edited my $PATH to give the precedence to a local architecture present in my $HOME directory. GCC must have been fetching some of its libraries from there which resulted in debug symbols not being fully generated.
Fixed it all by editing the $PATH variable back to the way it used to.
EDIT:
I finally found out the exact reason why it did not work. Basically as a temp fix I was simply setting in my $PATH my local-user bin folder where I compiled many system binaries for them to be up to date.
The binary ld (2.30.51.20180501) was causing the issue. Removing it from my $PATH allowed my valgrind to work as intended again.
I am using the Instruments from XCode 4.2.1 to find some memory leaks.
I have found a very weird (at least for me) memory leak:
(The function values_table_get_value returns a double, and output = stdout)
The two questions are:
Is it a real memory leak?
How can I clean up it? (The fprintf format %.3f is wrong for a double?
To show that the leak is inside the fprintf, I changed the return from the function to 5.0:
and moving the return to a temporary variable:
and to be more precise, here is a picture of the asm code that shows that the leak is:
I did a very simple test: printing using the sprintf + fprintf, but I get the leak at sprintf:
I also tried to use the printf directly, and I get the leak on it.
I am really thinking that the problem is in format.
The final try, to show that do not have anything related with my function:
Just to check, I executed with valgrind: (values_table_print is the function name)
valgrind --leak-check=full --show-reachable=yes ./leastsquares
My software versions:
valgrind --version: valgrind-3.7.0
gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Don't waste time debugging
Your setup probably has a bad gcc or valgrind build or simply isn't up-to-date.
I just tried:
gcc -o junk /tmp/junk.cpp && ~/src/valgrind/coregrind/valgrind --leak-check=full --show-reachable=yes /tmp/junk
on the following snippet
#include <stdio.h>
int main()
{
printf( "%.3f", 3.0 );
}
Configuration
OSX 10.7.2
valgrind-3.7.0.SVN
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Valgrind Output
==58980== Memcheck, a memory error detector
==58980== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==58980== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==58980== Command: /tmp/junk
==58980==
--58980-- /tmp/junk:
--58980-- dSYM directory is missing; consider using --dsymutil=yes
UNKNOWN task message [id 3229, to mach_task_self(), reply 0x2503]
UNKNOWN task message [id 3229, to mach_task_self(), reply 0x2503]
UNKNOWN task message [id 3414, to mach_task_self(), reply 0x2503]
--58980-- WARNING: unhandled syscall: unix:357
--58980-- You may be able to write your own handler.
--58980-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--58980-- Nevertheless we consider this a bug. Please report
--58980-- it at http://valgrind.org/support/bug_reports.html.
3.000==58980==
==58980== HEAP SUMMARY:
==58980== in use at exit: 0 bytes in 0 blocks
==58980== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==58980==
==58980== All heap blocks were freed -- no leaks are possible
==58980==
==58980== For counts of detected and suppressed errors, rerun with: -v
==58980== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I'm getting valgrind errors when attempting to pclose() a pipe previously open with popen(). The errors occur on Mac OS X, but not on Linux. Consider the following example:
#include <stdlib.h>
#include <stdio.h>
int main() {
FILE *fp;
char buf[4096];
if (!(fp = popen("ls", "r")))
exit(-1);
while (fscanf(fp, "%s", buf) == 1)
printf("%s\n", buf);
pclose(fp);
return 0;
}
I get the following valgrind errors on a Mac (OS X 10.6.7, valgrind version 3.6.0), except if I remove the pclose() call:
==21455== Conditional jump or move depends on uninitialised value(s)
==21455== at 0xB1992: pclose (in /usr/lib/libSystem.B.dylib)
==21455== by 0x1F16: main (in ./a.out)
==21455==
==21455== Syscall param wait4(pid) contains uninitialised byte(s)
==21455== at 0x504FA: wait4 (in /usr/lib/libSystem.B.dylib)
==21455== by 0x1F16: main (in ./a.out)
However, I don't get any errors on a Linux system with valgrind version 3.5.0.
Any ideas on what could be causing the errors on the Mac?
Update
Turning on --track-origins in valgrind shows that the origin of the problem might be in the popen() call. Got the same thing with gcc 4.2.1 and 4.5.3.
==4425== Conditional jump or move depends on uninitialised value(s)
==4425== at 0xB1992: pclose (in /usr/lib/libSystem.B.dylib)
==4425== by 0x1F18: main (in ./a.out)
==4425== Uninitialised value was created by a stack allocation
==4425== at 0xB14C5: popen$UNIX2003 (in /usr/lib/libSystem.B.dylib)
==4425==
==4425== Syscall param wait4(pid) contains uninitialised byte(s)
==4425== at 0x504FA: wait4 (in /usr/lib/libSystem.B.dylib)
==4425== by 0x1F18: main (in ./a.out)
==4425== Uninitialised value was created by a stack allocation
==4425== at 0xB14C5: popen$UNIX2003 (in /usr/lib/libSystem.B.dylib)
It is quite common for system libraries to pass uninitialized bytes to system calls. It is less common for conditional jump to depend on uninitialized value, but it does happen (glibc-2.X.supp in my Linux build contains 8 suppressions for this in glibc).
Since there is nothing you can do about these errors anyway, you should just suppress them. See --gen-suppressions in Valgrind docs.
The reported problem seems to be internal to the system library, not in your code.
I too get no errors using MacOS X 10.6.8, Valgrind 3.6.0, and either (Apple's) GCC 4.2.1 or (my) GCC 4.6.0. I do get compilation warnings from your code (4.6.0 shown) - actually, I have 'make' run the command and the makefile contains all those -Wxxx arguments:
$ gcc -g -std=c99 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition vg.c -o vg
vg.c:4:5: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
vg.c: In function ‘main’:
vg.c:4:5: warning: old-style function definition [-Wold-style-definition]
$ valgrind vg
==40593== Memcheck, a memory error detector
==40593== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==40593== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==40593== Command: vg
==40593==
vg
vg.c
vg.dSYM
==40593==
==40593== HEAP SUMMARY:
==40593== in use at exit: 4,184 bytes in 2 blocks
==40593== total heap usage: 6 allocs, 4 frees, 26,848 bytes allocated
==40593==
==40593== LEAK SUMMARY:
==40593== definitely lost: 0 bytes in 0 blocks
==40593== indirectly lost: 0 bytes in 0 blocks
==40593== possibly lost: 0 bytes in 0 blocks
==40593== still reachable: 4,184 bytes in 2 blocks
==40593== suppressed: 0 bytes in 0 blocks
==40593== Rerun with --leak-check=full to see details of leaked memory
==40593==
==40593== For counts of detected and suppressed errors, rerun with: -v
==40593== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ cc --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc --version
gcc (GCC) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ valgrind --version
valgrind-3.6.0
Localhost JL: uname -a
Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
$ otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 315.0.0)
When run with -v --gen-suppressions=yes, valgrind reports a lot more information, but there are still no suppressed errors.
This error appears resolved in latest Valgrind SVN source. A number of internal bugs in Valgrind have been resolved, as well as known Apple system library bugs suppressed.
Note this is running on OS X 10.10.4
$ ./vg-in-place ../../test
==55558== Memcheck, a memory error detector
==55558== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==55558== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==55558== Command: ../../test
==55558==
--55558-- ../../test:
--55558-- dSYM directory is missing; consider using --dsymutil=yes
AUTHORS
COPYING
COPYING.DOCS
Makefile
...
vg-in-place
xfree-3.supp
xfree-4.supp
==55558==
==55558== HEAP SUMMARY:
==55558== in use at exit: 39,331 bytes in 419 blocks
==55558== total heap usage: 523 allocs, 104 frees, 68,971 bytes allocated
==55558==
==55558== LEAK SUMMARY:
==55558== definitely lost: 0 bytes in 0 blocks
==55558== indirectly lost: 0 bytes in 0 blocks
==55558== possibly lost: 0 bytes in 0 blocks
==55558== still reachable: 0 bytes in 0 blocks
==55558== suppressed: 39,331 bytes in 419 blocks
==55558==
==55558== For counts of detected and suppressed errors, rerun with: -v
==55558== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ ./vg-in-place --version
valgrind-3.11.0.SVN