c++ - 使用 valgrind 在内存泄漏检测中抑制 "dl-hack3-cond-1"

Question

我正在使用 valgrind 来检测内存泄漏。 valgrind 的输出由命令生成

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

事实上，我的程序是一个高度简化的 python 解释器(作业 ToT)，正如您可以从名称 spython test.py 推断的那样

困扰我的是底部的输出

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

这是什么意思？我查了一下，在valgrind的抑制文件default.supp中没有dl-hack3-cond-1。 我想消除这个恼人的抑制错误(这意味着通过 valgrind 测试，而不是通过“抑制抑制”)。

这里是/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

我的 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

您的 valgrind 运行通过了。它说在 0 个上下文中有 0 个错误，不包括被抑制的错误。您不应该关心被抑制的错误，因为它们与您的代码无关。通常它们是系统库中的问题，因此无论如何您都无法修复它们。

在 dl-hack 抑制的情况下，它们与动态链接器有关。