|
From: Russ C. <ru...@gm...> - 2004-05-07 18:56:37
|
When I run
valgrind --tool=addrcheck --leak-check=yes
--leak-resolution=high --num-callers=15 --show-reachable=yes
on my program I get output like the below.
The frustrating thing is that for the blocks that are
definitely lost (and thus a lot more interesting!),
valgrind just tells me they were allocated with malloc.
Well, duh.
What can I do to help valgrind give me a more useful
stack trace?
I compile all source in my program with -ggdb and
-fno-omit-frame-pointer already. I tried compiling with -O0,
thinking that maybe somehow gcc was doing some funny
tail recursion, but that didn't change anything.
Thanks.
Russ
==17774== searching for pointers to 8952 not-freed blocks.
==17774== checked 146532176 bytes.
==17774==
==17774==
==17774== 8 bytes in 1 blocks are still reachable in loss record 1 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774== by 0x805D933: _threadmalloc (lib.c:10)
==17774== by 0x805DB33: p9main (main.c:61)
==17774== by 0x805FE96: main (main.c:11)
==17774==
==17774==
==17774== 144 bytes in 1 blocks are still reachable in loss record 2 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774== by 0x805D933: _threadmalloc (lib.c:10)
==17774== by 0x805C78C: newthread (create.c:26)
==17774== by 0x805CBC8: _newproc (create.c:150)
==17774== by 0x805DB6D: p9main (main.c:65)
==17774== by 0x805FE96: main (main.c:11)
==17774==
==17774==
==17774== 240 bytes in 1 blocks are still reachable in loss record 3 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774== by 0x805FF06: mallocz (mallocz.c:11)
==17774== by 0x8063F84: _p9uproc (_p9proc.c:48)
==17774== by 0x805FE84: main (main.c:10)
==17774==
==17774==
==17774== 2576 bytes in 1 blocks are still reachable in loss record 4 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774== by 0x805D933: _threadmalloc (lib.c:10)
==17774== by 0x805CB8B: _newproc (create.c:147)
==17774== by 0x805DB6D: p9main (main.c:65)
==17774== by 0x805FE96: main (main.c:11)
==17774==
==17774==
==17774== 32768 bytes in 1 blocks are still reachable in loss record 5 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774== by 0x805D933: _threadmalloc (lib.c:10)
==17774== by 0x805C79C: newthread (create.c:27)
==17774== by 0x805CBC8: _newproc (create.c:150)
==17774== by 0x805DB6D: p9main (main.c:65)
==17774== by 0x805FE96: main (main.c:11)
==17774==
==17774==
==17774== 1226040 bytes in 152 blocks are still reachable in loss record 6 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774==
==17774==
==17774== 33554432 bytes in 2048 blocks are possibly lost in loss record 7 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774==
==17774==
==17774== 109906268 bytes in 6747 blocks are definitely lost in loss
record 8 of 8
==17774== at 0x7501E8C1: malloc (vg_replace_malloc.c:105)
==17774==
==17774== LEAK SUMMARY:
==17774== definitely lost: 109906268 bytes in 6747 blocks.
==17774== possibly lost: 33554432 bytes in 2048 blocks.
==17774== still reachable: 1261776 bytes in 157 blocks.
==17774== suppressed: 0 bytes in 0 blocks.
|
|
From: Russ C. <ru...@gm...> - 2004-05-07 20:12:26
|
It turns out that my problem was that I was using a
user-level threads package, which can make Valgrind
sometimes think the stack is enormous and refuse to
record context.
This change seems like a good way to fix the problem.
Basically, if the stack appears to be very large, try searching
just a small amount (like one page) instead.
Where is the right place to send such patches?
I can't find it in the documentation.
Thanks.
Russ
diff -c -r1.13 vg_execontext.c
*** vg_execontext.c 16 Sep 2003 07:41:42 -0000 1.13
--- vg_execontext.c 7 May 2004 19:08:04 -0000
***************
*** 190,214 ****
/* If the stack is ridiculously big, don't poke around ... but
don't bomb out either. Needed to make John Regehr's
user-space threads package work. JRS 20021001 */
! eips[0] = eip;
! i = 1;
! } else {
! /* Get whatever we safely can ... */
! eips[0] = eip;
! for (i = 1; i < n_eips; i++) {
! if (!(ebp_min <= ebp && ebp <= ebp_max)) {
! //VG_(printf)("... out of range %p\n", ebp);
! break; /* ebp gone baaaad */
! }
! // NJN 2002-sep-17: monotonicity doesn't work -- gives
wrong traces...
! // if (ebp >= ((UInt*)ebp)[0]) {
! // VG_(printf)("nonmonotonic\n");
! // break; /* ebp gone nonmonotonic */
! // }
! eips[i] = ((UInt*)ebp)[1]; /* ret addr */
! ebp = ((UInt*)ebp)[0]; /* old ebp */
! //VG_(printf)(" %p\n", eips[i]);
}
}
n_found = i;
--- 190,214 ----
/* If the stack is ridiculously big, don't poke around ... but
don't bomb out either. Needed to make John Regehr's
user-space threads package work. JRS 20021001 */
! /* Still, it's nice to get some context out of the stack.
! Assume the first page or so is worth looking at. RSC 20040506 */
! ebp_max = ebp_min + VKI_BYTES_PER_PAGE;
! }
! /* Get whatever we safely can ... */
! eips[0] = eip;
! for (i = 1; i < n_eips; i++) {
! if (!(ebp_min <= ebp && ebp <= ebp_max)) {
! //VG_(printf)("... out of range %p\n", ebp);
! break; /* ebp gone baaaad */
}
+ // NJN 2002-sep-17: monotonicity doesn't work -- gives wrong traces...
+ // if (ebp >= ((UInt*)ebp)[0]) {
+ // VG_(printf)("nonmonotonic\n");
+ // break; /* ebp gone nonmonotonic */
+ // }
+ eips[i] = ((UInt*)ebp)[1]; /* ret addr */
+ ebp = ((UInt*)ebp)[0]; /* old ebp */
+ //VG_(printf)(" %p\n", eips[i]);
}
n_found = i;
|