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
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
