Re: [Valgrind-users] Didn't find deliberate leak

[Nicholas N. <nj...@ca...>]

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