2012-05-30 24 views
5

Tôi đang sử dụng valgrind để phát hiện rò rỉ bộ nhớ. đầu ra từ valgrind được tạo ra bởi lệnhđàn áp "dl-hack3-cond-1" trong phát hiện rò rỉ bộ nhớ bằng cách sử dụng valgrind

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

trên thực tế, chương trình của tôi là một thông dịch viên python đơn giản hóa cao (bài tập về nhà ToT) như bạn có thể suy ra từ tên spython test.py

điều đó làm tôi bực mình là đầu ra ở dưới cùng

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

điều này có nghĩa là gì? Tôi đã tra cứu và không có dl-hack3-cond-1 trong tệp đàn áp valgrind default.supp. Tôi muốn loại bỏ lỗi gây phiền nhiễu gây phiền nhiễu này (có nghĩa là PASS kiểm tra valgrind, không phải bằng cách 'triệt tiêu các áp chế').

đây là nội dung của/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 ([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) 

Trả lời

9

đàn áp Đó chắc chắn tồn tại đối với tôi trong default.supp tôi:

$ 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 

Và chạy valgrind của bạn đã qua. Nó nói rằng có 0 lỗi trong 0 ngữ cảnh, không bao gồm các lỗi bị chặn. Bạn không nên quan tâm đến các lỗi đã bị chặn, vì chúng không liên quan đến mã của bạn. Thông thường chúng là các vấn đề trong các thư viện hệ thống, và do đó bạn sẽ không có cách nào để sửa chúng.

Trong trường hợp ức chế dl-hack, chúng có liên quan đến trình liên kết động.

Các vấn đề liên quan