|
From: Jeremy F. <je...@go...> - 2005-03-01 06:25:56
|
CVS commit by fitzhardinge:
Make it so the thread-error printing machinery noticers its her in the
death sequence. Also: add a test case; getting more expert with knife+fork.
A tests/describe-block.c 1.1 [no copyright]
A tests/describe-block.stderr.exp 1.1
A tests/describe-block.vgtest 1.1
M +6 -2 mac_needs.c 1.34
M +1 -0 mac_shared.h 1.35
M +49 -24 docs/mc_main.html 1.14
M +3 -0 tests/Makefile.am 1.69
--- valgrind/memcheck/mac_needs.c #1.33:1.34
@@ -108,4 +108,5 @@ void clear_AddrInfo ( AddrInfo* ai )
ai->stack_tid = VG_INVALID_THREADID;
ai->maybe_gcc = False;
+ ai->desc = NULL;
}
@@ -229,6 +230,6 @@ void MAC_(pp_AddrInfo) ( Addr a, AddrInf
case Freed: case Mallocd: case UserG: case Mempool: {
SizeT delta;
- UChar* relative;
- UChar* kind;
+ const Char* relative;
+ const Char* kind;
if (ai->akind == Mempool) {
kind = "mempool";
@@ -236,4 +237,7 @@ void MAC_(pp_AddrInfo) ( Addr a, AddrInf
kind = "block";
}
+ if (ai->desc != NULL)
+ kind = ai->desc;
+
if (ai->rwoffset < 0) {
delta = (SizeT)(- ai->rwoffset);
--- valgrind/memcheck/mac_shared.h #1.34:1.35
@@ -66,4 +66,5 @@ typedef
ExeContext* lastchange; // Freed, Mallocd
ThreadId stack_tid; // Stack
+ const Char *desc; // UserG
Bool maybe_gcc; // True if just below %esp -- could be a gcc bug.
}
--- valgrind/memcheck/tests/Makefile.am #1.68:1.69
@@ -23,4 +23,5 @@
clientperm.stdout.exp clientperm.vgtest \
custom_alloc.stderr.exp custom_alloc.vgtest \
+ describe-block.stderr.exp describe-block.vgtest \
doublefree.stderr.exp doublefree.vgtest \
error_counts.stderr.exp error_counts.stdout.exp error_counts.vgtest \
@@ -89,4 +90,5 @@
badloop badpoll badrw brk brk2 buflen_check \
clientperm custom_alloc \
+ describe-block \
doublefree error_counts errs1 exitprog execve execve2 \
fprw fwrite hello inits inline \
@@ -126,4 +128,5 @@
clientperm_SOURCES = clientperm.c
custom_alloc_SOURCES = custom_alloc.c
+describe_block_SOURCES = describe-block.c
doublefree_SOURCES = doublefree.c
error_counts_SOURCES = error_counts.c
--- valgrind/memcheck/docs/mc_main.html #1.13:1.14
@@ -41,6 +41,5 @@
yet been free'd, but to which no pointer can be found. Such a
block can never be free'd by the program, since no pointer to it
- exists. Leak checking is disabled by default because it tends
- to generate dozens of error messages. </li><br><p>
+ exists. </li><br><p>
<li><code>--show-reachable=no</code> [default]<br>
@@ -56,5 +55,8 @@
indicate memory leaks, because you do not actually have a
pointer to the start of the block which you can hand to
- <code>free</code>, even if you wanted to. </li><br><p>
+ <code>free</code>, even if you wanted to.
+
+ <p> This option also shows indirectly leaked blocks (blocks
+ which are only referenced by other leaked blocks).</li><br><p>
<li><code>--leak-resolution=low</code> [default]<br>
@@ -737,13 +739,29 @@
at exit. But many programs do.
-<p>For each such block, Memcheck scans the entire address space of the
-process, looking for pointers to the block. One of three situations
-may result:
+<p>Technically, a leak is any allocated memory which won't be used
+again. Since Valgrind can't predict the future, it defines a leak as
+memory which has no pointers to it. Your program can't ever use such
+memory.
+
+<p>To find leaked blocks, Valgrind finds all the blocks which have not
+been leaked, by searching for pointers to them. Starting from the
+"root set" (static data, thread stacks and registers), it finds each
+immediately pointed-to block, and from those all the other blocks on
+the heap.
+
+<p>Once it has found all the unleaked blocks, the remaining blocks
+must be leaked. Rather than reporting on every single leaked block
+individually, it groups them into clusters of leaked blocks: leaked
+blocks which point to other leaked blocks. The blocks which it reports
+are the "heads" of each leaked cluster.
+
+There are two kinds of references to a block in memory:
<ul>
- <li>A pointer to the start of the block is found. This usually
- indicates programming sloppiness; since the block is still
+ <li>A pointer to the start of the block is found. This might
+ indicate programming sloppiness; since the block is still
pointed at, the programmer could, at least in principle, free'd
- it before program exit.</li><br>
+ it before program exit. It could also be a real leak, if a data
+ structure is growing without bound.
<p>
@@ -753,13 +771,6 @@
block as "dubious", that is, possibly leaked,
because it's unclear whether or
- not a pointer to it still exists.</li><br>
+ not a pointer to it still exists.
<p>
-
- <li>The worst outcome is that no pointer to the block can be found.
- The block is classified as "leaked", because the
- programmer could not possibly have free'd it at program exit,
- since no pointer to it exists. This might be a symptom of
- having lost the pointer at some earlier point in the
- program.</li>
</ul>
@@ -770,8 +781,17 @@
not have any leaked or dubious blocks at exit.
-<p>The precise area of memory in which Memcheck searches for pointers
-is: all naturally-aligned 4-byte words for which all A bits indicate
+
+
+<p>The precise areas in which Memcheck searches for pointers
+in the root set are:
+<ul>
+<li>Read-write mapped segments which are not part of the heap
+<li>The stack of each living thread, above the stack pointer
+<li>Integer registers of each living thread
+</ul>
+<p>Within these areas, and within the heap, it inspects each
+naturally-aligned 4-byte word for which all A bits indicate
addressibility and all V bits indicated that the stored value is
-actually valid.
+actually valid, and checks to see if it is a valid heap pointer.
<p>
@@ -790,11 +810,16 @@
ranges as completely inaccessible, accessible but containing
undefined data, and accessible and containing defined data,
- respectively. Subsequent errors may have their faulting
- addresses described in terms of these blocks. Returns a
- "block handle". Returns zero when not run on Valgrind.
+ respectively. Returns -1 when run under Valgrind, zero when
+ not run on Valgrind.
+<p>
+<li><code>VALGRIND_CREATE_BLOCK</code>: This describes a range
+ of memory using the supplied string; this string is displayed
+ for any error which relates to that range of memory. Returns
+ a block handle which can be used with
+ <code>VALGRIND_DISCARD</code>.
<p>
<li><code>VALGRIND_DISCARD</code>: At some point you may want
Valgrind to stop reporting errors in terms of the blocks
- defined by the previous three macros. To do this, the above
+ defined by the previous macro. To do this, the above
macros return a small-integer "block handle". You can pass
this block handle to <code>VALGRIND_DISCARD</code>. After
|