|
From: <sv...@va...> - 2011-11-24 17:06:35
|
Author: florian
Date: 2011-11-24 17:01:50 +0000 (Thu, 24 Nov 2011)
New Revision: 442
Log:
Do not refer to Ptrcheck. It has been renamed to SGCheck.
Modified:
trunk/docs/manual/dist.authors.html
trunk/docs/manual/dist.news.html
trunk/docs/manual/pc-manual.html
trunk/downloads/current.html
Modified: trunk/docs/manual/dist.authors.html
===================================================================
--- trunk/docs/manual/dist.authors.html 2011-11-24 16:21:17 UTC (rev 441)
+++ trunk/docs/manual/dist.authors.html 2011-11-24 17:01:50 UTC (rev 442)
@@ -24,7 +24,7 @@
<br>
JulianSewardwastheoriginalfounder,designerandauthorof<br>
Valgrind,createdthedynamictranslationframeworks,wroteMemcheck,<br>
-the3.XversionsofHelgrind,Ptrcheck,DHAT,anddidlotsofother<br>
+the3.XversionsofHelgrind,SGCheck,DHAT,anddidlotsofother<br>
things.<br>
<br>
NicholasNethercotedidthecore/toolgeneralisation,wrote<br>
Modified: trunk/docs/manual/dist.news.html
===================================================================
--- trunk/docs/manual/dist.news.html 2011-11-24 16:21:17 UTC (rev 441)
+++ trunk/docs/manual/dist.news.html 2011-11-24 17:01:50 UTC (rev 442)
@@ -103,7 +103,9 @@
(--join-list-vol);fixedamemoryleaktriggeredbyrepeatedclient<br>
memoryallocatationanddeallocation;improvedDarwinsupport.<br>
<br>
-*exp-ptrcheck:thistoolhasbeenreducedinscopesoastoimprove<br>
+*exp-ptrcheck:thistoolhasbeenrenamedtoexp-sgcheck<br>
+<br>
+*exp-sgcheck:thistoolhasbeenreducedinscopesoastoimprove<br>
performanceandremovecheckingthatMemcheckdoesbetter.<br>
Specifically,theabilitytocheckforoverrunsforstackandglobal<br>
arraysisunchanged,buttheabilitytocheckforoverrunsofheap<br>
Modified: trunk/docs/manual/pc-manual.html
===================================================================
--- trunk/docs/manual/pc-manual.html 2011-11-24 16:21:17 UTC (rev 441)
+++ trunk/docs/manual/pc-manual.html 2011-11-24 17:01:50 UTC (rev 442)
@@ -1,7 +1,7 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>11.Ptrcheck: an experimental heap, stack and global array overrun detector</title>
+<title>11.SGCheck: an experimental heap, stack and global array overrun detector</title>
<link rel="stylesheet" href="vg_basic.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.75.2">
<link rel="home" href="index.html" title="Valgrind Documentation">
@@ -17,16 +17,16 @@
<th align="center" valign="middle">Valgrind User Manual</th>
<td width="22px" align="center" valign="middle"><a accesskey="n" href="bbv-manual.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td>
</tr></table></div>
-<div class="chapter" title="11.Ptrcheck: an experimental heap, stack and global array overrun detector">
+<div class="chapter" title="11.SGCheck: an experimental heap, stack and global array overrun detector">
<div class="titlepage"><div><div><h2 class="title">
-<a name="pc-manual"></a>11.Ptrcheck: an experimental heap, stack and global array overrun detector</h2></div></div></div>
+<a name="pc-manual"></a>11.SGCheck: an experimental heap, stack and global array overrun detector</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="pc-manual.html#pc-manual.overview">11.1. Overview</a></span></dt>
-<dt><span class="sect1"><a href="pc-manual.html#pc-manual.options">11.2. Ptrcheck Command-line Options</a></span></dt>
-<dt><span class="sect1"><a href="pc-manual.html#pc-manual.how-works.heap-checks">11.3. How Ptrcheck Works: Heap Checks</a></span></dt>
-<dt><span class="sect1"><a href="pc-manual.html#pc-manual.how-works.sg-checks">11.4. How Ptrcheck Works: Stack and Global Checks</a></span></dt>
+<dt><span class="sect1"><a href="pc-manual.html#pc-manual.options">11.2. SGCheck Command-line Options</a></span></dt>
+<dt><span class="sect1"><a href="pc-manual.html#pc-manual.how-works.heap-checks">11.3. How SGCheck Works: Heap Checks</a></span></dt>
+<dt><span class="sect1"><a href="pc-manual.html#pc-manual.how-works.sg-checks">11.4. How SGCheck Works: Stack and Global Checks</a></span></dt>
<dt><span class="sect1"><a href="pc-manual.html#pc-manual.cmp-w-memcheck">11.5. Comparison with Memcheck</a></span></dt>
<dt><span class="sect1"><a href="pc-manual.html#pc-manual.limitations">11.6. Limitations</a></span></dt>
<dt><span class="sect1"><a href="pc-manual.html#pc-manual.todo-user-visible">11.7. Still To Do: User-visible Functionality</a></span></dt>
@@ -34,17 +34,17 @@
</dl>
</div>
<p>To use this tool, you must specify
-<code class="option">--tool=exp-ptrcheck</code> on the Valgrind
+<code class="option">--tool=exp-sgcheck</code> on the Valgrind
command line.</p>
<div class="sect1" title="11.1.Overview">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="pc-manual.overview"></a>11.1.Overview</h2></div></div></div>
-<p>Ptrcheck is a tool for finding overruns of heap, stack
+<p>SGCheck is a tool for finding overruns of heap, stack
and global arrays. Its functionality overlaps somewhat with
Memcheck's, but it is able to catch invalid accesses in a number of
cases that Memcheck would miss. A detailed comparison against
Memcheck is presented below.</p>
-<p>Ptrcheck is composed of two almost completely independent tools
+<p>SGCheck is composed of two almost completely independent tools
that have been glued together. One part,
in <code class="computeroutput">h_main.[ch]</code>, checks accesses
through heap-derived pointers. The other part, in
@@ -60,10 +60,10 @@
the likely forms of stack and global array accesses, and, as far as is
known, is entirely novel.</p>
</div>
-<div class="sect1" title="11.2.Ptrcheck Command-line Options">
+<div class="sect1" title="11.2.SGCheck Command-line Options">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="pc-manual.options"></a>11.2.Ptrcheck Command-line Options</h2></div></div></div>
-<p>Ptrcheck-specific command-line options are:</p>
+<a name="pc-manual.options"></a>11.2.SGCheck Command-line Options</h2></div></div></div>
+<p>SGCheck-specific command-line options are:</p>
<div class="variablelist">
<a name="pc.opts.list"></a><dl>
<dt>
@@ -72,12 +72,12 @@
[default: yes] </code>
</span>
</dt>
-<dd><p>By default, Ptrcheck checks for overruns of stack, global
+<dd><p>By default, SGCheck checks for overruns of stack, global
and heap arrays.
With <code class="varname">--enable-sg-checks=no</code>, the stack and
global array checks are omitted, and only heap checking is
performed. This can be useful because the stack and global
- checks are quite expensive, so omitting them speeds Ptrcheck up
+ checks are quite expensive, so omitting them speeds SGCheck up
a lot.
</p></dd>
<dt>
@@ -88,7 +88,7 @@
<dd>
<p>This option has the same meaning as it does for
Memcheck.</p>
-<p>Controls how Ptrcheck handles word-sized, word-aligned
+<p>Controls how SGCheck handles word-sized, word-aligned
loads which partially overlap the end of heap blocks -- that is,
some of the bytes in the word are validly addressable, but
others are not. When <code class="varname">yes</code>, such loads do not
@@ -105,21 +105,21 @@
</dl>
</div>
</div>
-<div class="sect1" title="11.3.How Ptrcheck Works: Heap Checks">
+<div class="sect1" title="11.3.How SGCheck Works: Heap Checks">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="pc-manual.how-works.heap-checks"></a>11.3.How Ptrcheck Works: Heap Checks</h2></div></div></div>
-<p>Ptrcheck can check for invalid uses of heap pointers, including
+<a name="pc-manual.how-works.heap-checks"></a>11.3.How SGCheck Works: Heap Checks</h2></div></div></div>
+<p>SGCheck can check for invalid uses of heap pointers, including
out of range accesses and accesses to freed memory. The mechanism is
however completely different from Memcheck's, and the checking is more
powerful.</p>
-<p>For each pointer in the program, Ptrcheck keeps track of which
+<p>For each pointer in the program, SGCheck keeps track of which
heap block (if any) it was derived from. Then, when an access is made
-through that pointer, Ptrcheck compares the access address with the
+through that pointer, SGCheck compares the access address with the
bounds of the associated block, and reports an error if the address is
out of bounds, or if the block has been freed.</p>
<p>Of course it is rarely the case that one wants to access a block
only at the exact address returned by <code class="function">malloc</code> et al.
-Ptrcheck understands that adding or subtracting offsets from a pointer to a
+SGCheck understands that adding or subtracting offsets from a pointer to a
block results in a pointer to the same block.</p>
<p>At a fundamental level, this scheme works because a correct
program cannot make assumptions about the addresses returned by
@@ -131,9 +131,9 @@
and subtracting other non-pointer values. Almost all other operations
produce a value which cannot possibly be a valid pointer.</p>
</div>
-<div class="sect1" title="11.4.How Ptrcheck Works: Stack and Global Checks">
+<div class="sect1" title="11.4.How SGCheck Works: Stack and Global Checks">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="pc-manual.how-works.sg-checks"></a>11.4.How Ptrcheck Works: Stack and Global Checks</h2></div></div></div>
+<a name="pc-manual.how-works.sg-checks"></a>11.4.How SGCheck Works: Stack and Global Checks</h2></div></div></div>
<p>When a source file is compiled
with <code class="option">-g</code>, the compiler attaches DWARF3
debugging information which describes the location of all stack and
@@ -164,7 +164,7 @@
access <code class="computeroutput">a[]</code>. Then, on the 11th
iteration, it accesses somewhere else, possibly a different local,
possibly an un-accounted for area of the stack (eg, spill slot), so
-Ptrcheck reports an error.</p>
+SGCheck reports an error.</p>
<p>There is an important caveat.</p>
<p>Imagine a function such as <code class="function">memcpy</code>, which is used
to read and write many different areas of memory over the lifetime of the
@@ -172,7 +172,7 @@
copying loop only ever access one particular stack or global variable, we
will be flooded with errors resulting from calls to
<code class="function">memcpy</code>.</p>
-<p>To avoid this problem, Ptrcheck instantiates fresh likely-target
+<p>To avoid this problem, SGCheck instantiates fresh likely-target
records for each entry to a function, and discards them on exit. This
allows detection of cases where (e.g.) <code class="function">memcpy</code> overflows
its source or destination buffers for any specific call, but does not carry
@@ -184,9 +184,9 @@
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="pc-manual.cmp-w-memcheck"></a>11.5.Comparison with Memcheck</h2></div></div></div>
<p>Memcheck does not do any access checks for stack or global arrays, so
-the presence of those in Ptrcheck is a straight win. (But see
+the presence of those in SGCheck is a straight win. (But see
"Limitations" below).</p>
-<p>Memcheck and Ptrcheck use different approaches for checking heap
+<p>Memcheck and SGCheck use different approaches for checking heap
accesses. Memcheck maintains bitmaps telling it which areas of memory
are accessible and which are not. If a memory access falls in an
unaccessible area, it reports an error. By marking the 16 bytes
@@ -200,18 +200,18 @@
fails to detect invalid accesses which just happen to fall within some
other valid area. This is not improbable, especially in crowded areas
of the process' address space.</p>
-<p>Ptrcheck's approach is to keep track of pointers derived from
+<p>SGCheck's approach is to keep track of pointers derived from
heap blocks. It tracks pointers which are derived directly from calls
to <code class="function">malloc</code> et al, but also ones derived indirectly, by
adding or subtracting offsets from the directly-derived pointers. When a
-pointer is finally used to access memory, Ptrcheck compares the access
+pointer is finally used to access memory, SGCheck compares the access
address with that of the block it was originally derived from, and
reports an error if the access address is not within the block
bounds.</p>
-<p>Consequently Ptrcheck can detect any out of bounds access
+<p>Consequently SGCheck can detect any out of bounds access
through a heap-derived pointer, no matter how far from the original
block it is.</p>
-<p>A second advantage is that Ptrcheck is better at detecting
+<p>A second advantage is that SGCheck is better at detecting
accesses to blocks freed very far in the past. Memcheck can detect
these too, but only for blocks freed relatively recently. To detect
accesses to a freed block, Memcheck must make it inaccessible, hence
@@ -219,24 +219,24 @@
the blocks are large, Memcheck will have to make them available for
re-allocation relatively quickly, thereby losing the ability to detect
invalid accesses to them.</p>
-<p>By contrast, Ptrcheck has a constant per-block space requirement
+<p>By contrast, SGCheck has a constant per-block space requirement
of four machine words, for detection of accesses to freed blocks. A
-freed block can be reallocated immediately, yet Ptrcheck can still
+freed block can be reallocated immediately, yet SGCheck can still
detect all invalid accesses through any pointers derived from the old
allocation, providing only that the four-word descriptor for the old
allocation is stored. For example, on a 64-bit machine, to detect
-accesses in any of the most recently freed 10 million blocks, Ptrcheck
+accesses in any of the most recently freed 10 million blocks, SGCheck
will require only 320MB of extra storage. Achieving the same level of
detection with Memcheck is close to impossible and would likely
involve several gigabytes of extra storage.</p>
<p>Having said all that, remember that Memcheck performs uninitialised
value checking, invalid and mismatched free checking, overlap checking, and
-leak checking, none of which Ptrcheck do. Memcheck has also benefitted from
+leak checking, none of which SGCheck do. Memcheck has also benefitted from
years of refinement, tuning, and experience with production-level usage, and
-so is much faster than Ptrcheck as it currently stands.
+so is much faster than SGCheck as it currently stands.
</p>
<p>Consequently we recommend you first make your programs run Memcheck
-clean. Once that's done, try Ptrcheck to see if you can shake out any
+clean. Once that's done, try SGCheck to see if you can shake out any
further heap, global or stack errors.</p>
</div>
<div class="sect1" title="11.6.Limitations">
@@ -247,27 +247,27 @@
programs. There are a number of limitations which you should be aware
of.</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>Heap checks: Ptrcheck can occasionally lose track of, or
+<li class="listitem"><p>Heap checks: SGCheck can occasionally lose track of, or
become confused about, which heap block a given pointer has been
derived from. This can cause it to falsely report errors, or to
miss some errors. This is not believed to be a serious
problem.</p></li>
-<li class="listitem"><p>Heap checks: Ptrcheck only tracks pointers that are stored
+<li class="listitem"><p>Heap checks: SGCheck only tracks pointers that are stored
properly aligned in memory. If a pointer is stored at a misaligned
- address, and then later read again, Ptrcheck will lose track of
+ address, and then later read again, SGCheck will lose track of
what it points at. Similar problem if a pointer is split into
pieces and later reconsitituted.</p></li>
-<li class="listitem"><p>Heap checks: Ptrcheck needs to "understand" which system
+<li class="listitem"><p>Heap checks: SGCheck needs to "understand" which system
calls return pointers and which don't. Many, but not all system
- calls are handled. If an unhandled one is encountered, Ptrcheck will
+ calls are handled. If an unhandled one is encountered, SGCheck will
abort. Fortunately, adding support for a new syscall is very
easy.</p></li>
-<li class="listitem"><p>Stack checks: It follows from the description above (<a class="xref" href="pc-manual.html#pc-manual.how-works.sg-checks" title="11.4.How Ptrcheck Works: Stack and Global Checks">How Ptrcheck Works: Stack and Global Checks</a>) that the first access by a
+<li class="listitem"><p>Stack checks: It follows from the description above (<a class="xref" href="pc-manual.html#pc-manual.how-works.sg-checks" title="11.4.How SGCheck Works: Stack and Global Checks">How SGCheck Works: Stack and Global Checks</a>) that the first access by a
memory referencing instruction to a stack or global array creates an
association between that instruction and the array, which is checked on
subsequent accesses by that instruction, until the containing function
exits. Hence, the first access by an instruction to an array (in any
- given function instantiation) is not checked for overrun, since Ptrcheck
+ given function instantiation) is not checked for overrun, since SGCheck
uses that as the "example" of how subsequent accesses should
behave.</p></li>
<li class="listitem">
@@ -302,10 +302,10 @@
startup quite slow. You can expect debuginfo reading time to be in
the region of a minute for an OpenOffice sized application, on a
2.4 GHz Core 2 machine. Reading this information also requires a
- lot of memory. To make it viable, Ptrcheck goes to considerable
+ lot of memory. To make it viable, SGCheck goes to considerable
trouble to compress the in-memory representation of the DWARF3
data, which is why the process of reading it appears slow.</p></li>
-<li class="listitem"><p>Performance: Ptrcheck runs slower than Memcheck. This is
+<li class="listitem"><p>Performance: SGCheck runs slower than Memcheck. This is
partly due to a lack of tuning, but partly due to algorithmic
difficulties. The heap-check side is potentially quite fast. The
stack and global checks can sometimes require a number of range
@@ -314,23 +314,23 @@
</p></li>
<li class="listitem">
<p>Coverage: the heap checking is relatively robust, requiring
- only that Ptrcheck can see calls to <code class="function">malloc</code> et al.
+ only that SGCheck can see calls to <code class="function">malloc</code> et al.
In that sense it has debug-info requirements comparable with Memcheck,
and is able to heap-check programs even with no debugging information
attached.</p>
<p>Stack/global checking is much more fragile. If a shared
- object does not have debug information attached, then Ptrcheck will
+ object does not have debug information attached, then SGCheck will
not be able to determine the bounds of any stack or global arrays
defined within that shared object, and so will not be able to check
accesses to them. This is true even when those arrays are accessed
from some other shared object which was compiled with debug
info.</p>
-<p>At the moment Ptrcheck accepts objects lacking debuginfo
- without comment. This is dangerous as it causes Ptrcheck to
+<p>At the moment SGCheck accepts objects lacking debuginfo
+ without comment. This is dangerous as it causes SGCheck to
silently skip stack and global checking for such objects. It would
be better to print a warning in such circumstances.</p>
</li>
-<li class="listitem"><p>Coverage: Ptrcheck checks that the areas read or written by
+<li class="listitem"><p>Coverage: SGCheck checks that the areas read or written by
system calls do not overrun heap blocks. But it doesn't currently
check them for overruns stack and global arrays. This would be
easy to add.</p></li>
Modified: trunk/downloads/current.html
===================================================================
--- trunk/downloads/current.html 2011-11-24 16:21:17 UTC (rev 441)
+++ trunk/downloads/current.html 2011-11-24 17:01:50 UTC (rev 442)
@@ -37,8 +37,11 @@
been added, so you can now control your application from inside GDB
whilst it runs on Valgrind. There have been performance and
functionality improvements for the following tools: Helgrind, DRD,
-Memcheck and exp-Ptrcheck.</p>
+Memcheck and exp-Sgcheck.</p>
+<p>The tool formerly known as exp-Ptrcheck has been renamed to exp-SGCheck.
+</p>
+
<p>This release supports X86/Linux, AMD64/Linux, ARM/Linux,
PPC32/Linux, PPC64/Linux, S390X/Linux,
ARM/Android (2.3.x),
|