|
From: Crispin F. <cr...@th...> - 2003-05-14 09:39:00
|
Hi,
While attempting to locate all the memory in a program that wasn't
freed, I came across an odd behaviour.
Using the following program:
== START ==
static char * bar = 0;
static char * bar1 = 0;
void do_stuff1()
{
bar = new char[1024];
}
void do_stuff()
{
bar1 = new char[1024];
}
int main( int argc, char ** argv )
{
do_stuff();
do_stuff1();
}
== END ==
(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?
Cheers
|
|
From: Bastien C. <ba...@ch...> - 2003-05-14 09:45:25
|
On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote:
> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
> [...]
> I get only 2 unreachable blocks, but both with the same stacktrace:
Does using the --num-callers option help?
Salut,
Bastien
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Crispin F. <cr...@th...> - 2003-05-14 09:59:52
|
On Wed, 2003-05-14 at 10:45, Bastien Chevreux wrote: > On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote: > > While attempting to locate all the memory in a program that wasn't > > freed, I came across an odd behaviour. > > [...] > > I get only 2 unreachable blocks, but both with the same stacktrace: > > Does using the --num-callers option help? No, I just get a longer stacktrace :) Crispin |
|
From: Bastien C. <ba...@ch...> - 2003-05-14 10:15:25
|
On Wednesday 14 May 2003 11:58, Crispin Flowerday wrote:
> No, I just get a longer stacktrace :)
Confirmed :-/ (with valgrind 1.9.5 and gcc3.3) Compiling with -g didn't help
either, it really shows the same line for both leaks. As no optimization
option is used for the compiler, I'd say that it's a bug. Now whether it's
the compiler or valgrind ...
Salut,
Bastien
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 10:09:32
|
On 14 May 2003, Crispin Flowerday wrote:
> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
>
> Using the following program:
>
> == START ==
>
> static char * bar = 0;
> static char * bar1 = 0;
>
> void do_stuff1()
> {
> bar = new char[1024];
> }
>
> void do_stuff()
> {
> bar1 = new char[1024];
> }
>
> int main( int argc, char ** argv )
> {
> do_stuff();
> do_stuff1();
> }
>
> == END ==
>
> (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...
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 10:19:22
|
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 |
|
From: Crispin F. <cr...@th...> - 2003-05-14 10:35:03
|
> 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.) Ahh, that explains it. Perhaps the leak-resolution should default to med or high as the output was extremely confusing (much worse when you have a large application and valgrind has merged 10 blocks into a single stacktrace). Cheers Crispin |
|
From: Richard B. <ri...@ta...> - 2003-05-14 12:50:57
|
On Wed, 2003-05-14 at 11:33, Crispin Flowerday wrote: > Ahh, that explains it. Perhaps the leak-resolution should default to med > or high as the output was extremely confusing (much worse when you have > a large application and valgrind has merged 10 blocks into a single > stacktrace). Wouldn't that result in confusing, or at least excessively repetitive, output when the same leak is happening multiple times when called from different places? How about changing the leak checker to compare the names up to the first name in the stack trace that isn't in part of valgrind? This would exclude the allocation functions quite neatly, which seems desirable. Perhaps there are problems with this that I can't see, though. Incidentally, I was going to try putting a patch for this together, but can't seem to update my checkout of valgrind CVS. In fact, I can't even do the cvs login: $ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind CVS password: cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused (just pressing return for the password) Is this just me and the lightning storms around here, or is it sourceforge? -- Richard |
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 13:01:40
|
On 14 May 2003, Richard Boulton wrote: > Incidentally, I was going to try putting a patch for this together, but > can't seem to update my checkout of valgrind CVS. In fact, I can't even > do the cvs login: > > $ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login > Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind > CVS password: > cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused > > (just pressing return for the password) > > Is this just me and the lightning storms around here, or is it sourceforge? SourceForge does that sometimes, try again or wait a while. N |
|
From: Crispin F. <cr...@th...> - 2003-05-14 13:08:22
|
On Wed, 2003-05-14 at 13:49, Richard Boulton wrote: > Wouldn't that result in confusing, or at least excessively repetitive, > output when the same leak is happening multiple times when called from > different places? Hmm I hadn't thought of that :) > How about changing the leak checker to compare the names up to the first > name in the stack trace that isn't in part of valgrind? This would > exclude the allocation functions quite neatly, which seems desirable. > Perhaps there are problems with this that I can't see, though. That seems like a pretty good solution, the slight problem however is that things such as strdup() aren't provided by valgrind, but will cause a malloc() to be performed, but the actual location of the leak is in the function above. (there may only be a small number of functions like that and these could possibly be special cased to go up another level). Crispin |