2012-05-30 10 views
5

Estoy usando valgrind para detectar fugas de memoria. la salida de valgrind es generada por el comandosupresión "dl-hack3-cond-1" en la detección de fuga de memoria usando valgrind

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

de hecho, mi programa es un intérprete de Python muy simplificado (tarea CpC) como se puede inferir a partir del nombre spython test.py

lo que me molesta es la salida en la parte inferior

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

¿Qué significa esto? He buscado y no hay dl-hack3-cond-1 en el archivo de supresión de valgrind default.supp. Quiero eliminar este molesto error suprimido (lo que significa PASAR la prueba valgrind, no por 'suprimir las supresiones').

aquí es el contenido de/tmp/registro:

==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 ([email protected]) (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 ([email protected]@GLIBC_2.14) redirected to 0x4a24620 (_vgnU_ifunc_wrapper) 
--24269-- REDIR: 0x576b790 (__memcpy_ssse3_back) redirected to 0x4c2c1a0 ([email protected]@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) 

Respuesta

9

que la supresión ciertamente existe para mí en mi 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 

Y su carrera valgrind está pasando. Dice que hubo 0 errores en 0 contextos, sin incluir los errores suprimidos. No debería preocuparse por los errores que se suprimieron, ya que no están relacionados con su código. Por lo general, son problemas en las bibliotecas del sistema, por lo que no tendría manera de solucionarlos de todos modos.

En el caso de las supresiones de dl-hack, están relacionadas con el enlazador dinámico.

Cuestiones relacionadas