使用valgrind在内存泄漏检测中抑制“dl-hack3-cond-1”

Question

I am using valgrind to detect memory leaks. the output from valgrind is generated by command

valgrind -v --leak-check=full ../spython test.py 2>/tmp/log

in fact, my program is a highly simplified python interpreter (homework ToT) as you can infer from the name spython test.py

the thing that bothers me is the output at bottom

==24269== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)
--24269-- 
--24269-- used_suppression:      3 dl-hack3-cond-1

what does this mean? I've look up, and there's no dl-hack3-cond-1 in valgrind's suppression file default.supp . I want to eliminate this annoying suppressed error (which means PASS the valgrind test, not by 'suppress the suppressions').

here is the content of /tmp/log:

==24269== Memcheck, a memory error detector
==24269== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24269== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24269== Command: ../spython test.py
==24269== 
--24269-- Valgrind options:
--24269--    -v
--24269--    --leak-check=full
--24269-- Contents of /proc/version:
--24269--   Linux version 3.3.2-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.0 20120407 (prerelease) (GCC) ) #1 SMP PREEMPT Sat Apr 14 09:48:37 CEST 2012
--24269-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--24269-- Page sizes: currently 4096, max supported 4096
--24269-- Valgrind library directory: /usr/lib/valgrind
--24269-- Reading syms from /home/tim/oop-2012-spring-spython/bin/spython (0x400000)
--24269-- Reading syms from /lib/ld-2.15.so (0x4000000)
--24269-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux (0x38000000)
--24269--    object doesn't have a symbol table
--24269--    object doesn't have a dynamic symbol table
--24269-- Reading suppressions file: /usr/lib/valgrind/default.supp
==24269== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-24269-by-tim-on-???
==24269== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-24269-by-tim-on-???
==24269== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-24269-by-tim-on-???
==24269== 
==24269== TO CONTROL THIS PROCESS USING vgdb (which you probably
==24269== don't want to do, unless you know exactly what you're doing,
==24269== or are doing some strange experiment):
==24269==   /usr/lib/valgrind/../../bin/vgdb --pid=24269 ...command...
==24269== 
==24269== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==24269==   /path/to/gdb ../spython
==24269== and then give GDB the following command
==24269==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=24269
==24269== --pid is optional if only one valgrind process is running
==24269== 
--24269-- REDIR: 0x4017a20 (strlen) redirected to 0x380625a7 (???)
--24269-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so (0x4a24000)
--24269--    object doesn't have a symbol table
--24269-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4c26000)
--24269--    object doesn't have a symbol table
--24269-- REDIR: 0x4017890 (index) redirected to 0x4c2aed0 (index)
--24269-- REDIR: 0x4017910 (strcmp) redirected to 0x4c2be90 (strcmp)
--24269-- Reading syms from /usr/lib/libstdc++.so.6.0.17 (0x4e31000)
--24269--    object doesn't have a symbol table
--24269-- Reading syms from /lib/libm-2.15.so (0x5135000)
--24269--    object doesn't have a symbol table
--24269-- Reading syms from /usr/lib/libgcc_s.so.1 (0x542a000)
--24269--    object doesn't have a symbol table
--24269-- Reading syms from /lib/libc-2.15.so (0x563f000)
--24269-- REDIR: 0x56c73a0 (strncasecmp) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x56c1470 (strnlen) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x56c50e0 (strcasecmp) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x56c2e60 (__GI_strrchr) redirected to 0x4c2acf0 (__GI_strrchr)
--24269-- REDIR: 0x56c1340 (strlen) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x57863d0 (__strlen_sse2_pminub) redirected to 0x4c2b210 (strlen)
--24269-- REDIR: 0x4e90430 (operator new(unsigned long)) redirected to 0x4c2a3d0 (operator new(unsigned long))
--24269-- REDIR: 0x56c9a70 (memcpy@@GLIBC_2.14) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x576b790 (__memcpy_ssse3_back) redirected to 0x4c2c1a0 (memcpy@@GLIBC_2.14)
--24269-- REDIR: 0x56c38a0 (bcmp) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x5780d00 (__memcmp_sse4_1) redirected to 0x4c2cf10 (bcmp)
--24269-- REDIR: 0x56bbab0 (malloc) redirected to 0x4c2a8d0 (malloc)
--24269-- REDIR: 0x4e8e750 (operator delete(void*)) redirected to 0x4c296c0 (operator delete(void*))
--24269-- REDIR: 0x4e90540 (operator new[](unsigned long)) redirected to 0x4c29e30 (operator new[](unsigned long))
--24269-- REDIR: 0x56c3ec0 (memset) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x56c3f00 (__GI_memset) redirected to 0x4c2d2f0 (memset)
--24269-- REDIR: 0x56bbfd0 (free) redirected to 0x4c29a30 (free)
--24269-- REDIR: 0x4e8e780 (operator delete[](void*)) redirected to 0x4c292a0 (operator delete[](void*))
--24269-- REDIR: 0x56cada0 (__GI___rawmemchr) redirected to 0x4c2d670 (__GI___rawmemchr)
--24269-- REDIR: 0x56c1390 (__GI_strlen) redirected to 0x4c2b230 (__GI_strlen)
--24269-- REDIR: 0x56bf850 (strcmp) redirected to 0x4a24620 (_vgnU_ifunc_wrapper)
--24269-- REDIR: 0x5759bb0 (__strcmp_sse42) redirected to 0x4c2bdd0 (strcmp)
--24269-- REDIR: 0x56cafb0 (strchrnul) redirected to 0x4c2d620 (strchrnul)
==24269== 
==24269== HEAP SUMMARY:
==24269==     in use at exit: 0 bytes in 0 blocks
==24269==   total heap usage: 39,501 allocs, 39,501 frees, 973,647 bytes allocated
==24269== 
==24269== All heap blocks were freed -- no leaks are possible
==24269== 
==24269== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)
--24269-- 
--24269-- used_suppression:      3 dl-hack3-cond-1
==24269== 
==24269== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)

Answer 1

That suppression certainly exists for me in my default.supp:

$ grep dl-hack $(locate default.supp | grep /usr)
   dl-hack3-cond-0
   dl-hack3-cond-1
   dl-hack3-cond-2
   dl-hack3-cond-3
   dl-hack3-cond-4
   dl-hack4-64bit-addr-1
   dl-hack4-64bit-addr-2
   dl-hack4-64bit-addr-3
   dl-hack5-32bit-addr-1
   dl-hack5-32bit-addr-3
   dl-hack5-32bit-addr-4

And your valgrind run is passing. It says there were 0 errors in 0 contexts, not including the suppressed errors. You shouldn't care about the errors that were suppressed, since they aren't related to your code. Typically they are issues in the system libraries, and so you would have no way to fix them anyway.

In the case of dl-hack suppressions, they are related to the dynamic linker.