Re: [Valgrind-users] Seemingly wrong reachable-memory reporting

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

On Wed, 14 May 2003, Nicholas Nethercote wrote:

> > While attempting to locate all the memory in a program that wasn't
> > freed, I came across an odd behaviour.

[snip]

> > (compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'
> >
> > I get only 2 unreachable blocks, but both with the same stacktrace:
> >
> > 2048 bytes in 2 blocks are still reachable in loss record 1 of 1
> >    at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
> >    by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
> >    by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
> >    by 0x8048470: main (in /home/crispin/src/tmp/main)
> >
> > Surely I should get 2 different stacktraces?
>
> I get the same with gcc 3.2.3.  But with gcc 2.96 I get two stack traces.
> Hmm, not sure...

Ah;  by default, the leak checker only compares the first two names in the
stack trace for the purposes of merging leak record.  Try
--leak-resolution=med.

(2.96 gave two leak records because it didn't have the "operator new[]"
line in the stack trace, so dostuff/dostuff1 made it into the first two
names.)

N