|
From: Vikas R. <min...@gm...> - 2009-02-05 21:09:37
|
Valgrind does not consider memory leaks to be errors. e.g.: valgrind --leak-check=full --error-exitcode=1 ./a.out ==13671== ==13671== 38 (8 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 2 ==13671== at 0x4A06019: operator new(unsigned long) (vg_replace_malloc.c:167) ==13671== by 0x400A31: main (in /home/vikas/valgrind_tests/a.out) myhost:myname valgrind_tests $ valgrind --leak-check=full --error-exitcode=1 ./a.out ==13672== Memcheck, a memory error detector. ==13672== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==13672== Using LibVEX rev 1658, a library for dynamic binary translation. ==13672== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==13672== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==13672== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==13672== For more details, rerun with: -v ==13672== ==13672== ==13672== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1) ==13672== malloc/free: in use at exit: 38 bytes in 2 blocks. ==13672== malloc/free: 3 allocs, 1 frees, 68 bytes allocated. ==13672== For counts of detected errors, rerun with: -v ==13672== searching for pointers to 2 not-freed blocks. ==13672== checked 162,952 bytes. ==13672== ==13672== 38 (8 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 2 ==13672== at 0x4A06019: operator new(unsigned long) (vg_replace_malloc.c:167) ==13672== by 0x400A31: main (in /home/vikas/valgrind_tests/a.out) ==13672== ==13672== LEAK SUMMARY: ==13672== definitely lost: 8 bytes in 1 blocks. ==13672== indirectly lost: 30 bytes in 1 blocks. ==13672== possibly lost: 0 bytes in 0 blocks. ==13672== still reachable: 0 bytes in 0 blocks. ==13672== suppressed: 0 bytes in 0 blocks. ==13672== Reachable blocks (those to which a pointer was found) are not shown. ==13672== To see them, rerun with: --show-reachable=yes myhost:myname valgrind_tests $ echo $? 0 As a consequence (or perhaps in addition), --db-attach does not cause valgrind to break into the debugger when a memory leak is encountered. Is there a way to tell valgrind to treat memory leaks as errors? If not, is there a way to break into the debugger when a memory leak is encountered? Thanks, -Vikas |