|
From: Darren C. <da...@dc...> - 2004-01-26 06:45:18
|
Hi, I just installed valgrind from source, default configuration, and tried it on a C++ program with a memory leak I'd inserted, specifically I added this line, with no delete: char *myleak=new char[777];myleak[0]='x';myleak[1]=0; //TEMP! But it says no errors [1]; it also says no malloc'd blocks. (my program doesn't spawn children but I added that line just to be sure after reading the FAQ). I'm compiling with -g3, no optimizations, using g++ 3.2 on RH8. Is this a bug or do I need to add some command-line option to get it to work with C++ programs? Darren [1]: $ valgrind -v --leak-check=yes --trace-children=yes ./9.apd_1.exe ==14950== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==14950== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==14950== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==14950== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==14950== Command line: ==14950== ./9.apd_1.exe ==14950== Startup, with flags: ==14950== --suppressions=/usr/local/lib/valgrind/default.supp ==14950== -v ==14950== --leak-check=yes ==14950== --trace-children=yes ==14950== Reading syms from /home/darren/Projects/ago3/tests/9.apd_1.exe ==14950== Reading syms from /lib/ld-2.3.2.so ==14950== object doesn't have a symbol table ==14950== object doesn't have any debug info ==14950== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so ==14950== Reading syms from /usr/local/lib/valgrind/valgrind.so ==14950== Reading syms from /usr/lib/libstdc++.so.5.0.1 ==14950== Reading syms from /lib/i686/libm-2.3.2.so ==14950== object doesn't have a symbol table ==14950== object doesn't have any debug info ==14950== Reading syms from /lib/libgcc_s-3.2-20020903.so.1 ==14950== Reading syms from /lib/i686/libc-2.3.2.so ==14950== object doesn't have a symbol table ==14950== object doesn't have any debug info ==14950== Reading suppressions file: /usr/local/lib/valgrind/default.supp ==14950== Estimated CPU clock rate is 2007 MHz ==14950== ==14950== ==14950== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==14950== malloc/free: in use at exit: 0 bytes in 0 blocks. ==14950== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==14950== ==14950== No malloc'd blocks -- no leaks are possible. --14950-- TT/TC: 0 tc sectors discarded. --14950-- 2788 chainings, 0 unchainings. --14950-- translate: new 4041 (64557 -> 848058; ratio 131:10) --14950-- discard 0 (0 -> 0; ratio 0:10). --14950-- dispatch: 5050000 jumps (bb entries), of which 339308 (6%) were unchained. --14950-- 103/5057 major/minor sched events. 4104 tt_fast misses. --14950-- reg-alloc: 508 t-req-spill, 158757+3291 orig+spill uis, 19742 total-reg-r. --14950-- sanity: 104 cheap, 5 expensive checks. --14950-- ccalls: 18348 C calls, 57% saves+restores avoided (61672 bytes) --14950-- 24848 args, avg 0.88 setup instrs each (5570 bytes) --14950-- 0% clear the stack (55044 bytes) --14950-- 5370 retvals, 33% of reg-reg movs avoided (3462 bytes) |
|
From: Nicholas N. <nj...@ca...> - 2004-01-26 08:51:53
|
On Mon, 26 Jan 2004, Darren Cook wrote:
> I just installed valgrind from source, default configuration, and tried it
> on a C++ program with a memory leak I'd inserted, specifically I added this
> line, with no delete:
> char *myleak=new char[777];myleak[0]='x';myleak[1]=0; //TEMP!
>
> But it says no errors [1]; it also says no malloc'd blocks. (my program
> doesn't spawn children but I added that line just to be sure after reading
> the FAQ).
>
> I'm compiling with -g3, no optimizations, using g++ 3.2 on RH8.
>
> Is this a bug or do I need to add some command-line option to get it to work
> with C++ programs?
I just tried this program:
int main(void) {
char *myleak=new char[777];
myleak[0]='x';
myleak[1]=0;
return 0;
}
and it found the leak as expected (output below).
Can you try this example program? That would help us know whether the
problem is caused by something else in your program. Do you override
'new'? I think that sometimes causes problems.
N
[~/grind/redux2] vg4 --leak-check=yes a.out
==2823== Memcheck, a memory error detector for x86-linux.
==2823== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==2823== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==2823== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==2823== For more details, rerun with: -v
==2823==
==2823==
==2823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==2823== malloc/free: in use at exit: 777 bytes in 1 blocks.
==2823== malloc/free: 1 allocs, 0 frees, 777 bytes allocated.
==2823== For counts of detected errors, rerun with: -v
==2823== searching for pointers to 1 not-freed blocks.
==2823== checked 2310200 bytes.
==2823==
==2823== 777 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2823== at 0x3C01E5C0: operator new[](unsigned) (vg_replace_malloc.c:113)
==2823== by 0x804843C: main (in /auto/homes/njn25/grind/redux2/a.out)
==2823==
==2823== LEAK SUMMARY:
==2823== definitely lost: 777 bytes in 1 blocks.
==2823== possibly lost: 0 bytes in 0 blocks.
==2823== still reachable: 0 bytes in 0 blocks.
==2823== suppressed: 0 bytes in 0 blocks.
==2823== Reachable blocks (those to which a pointer was found) are not shown.
==2823== To see them, rerun with: --show-reachable=yes
|
|
From: Darren C. <da...@dc...> - 2004-01-26 09:24:38
|
> Can you try this example program? That would help us know whether the > problem is caused by something else in your program. Do you override > 'new'? I think that sometimes causes problems. Thanks - your example program worked as expected. And my earlier program now catches the problem as well. I think I was still linking in with the dmalloc library when I did the below tests (I should've guessed they'd be incompatible). Sorry for the noise. Darren |