Valgrind BBV, Быстрый старт

Страница: 168 / 319

SGCheck: an experimental stack and global array overrun detector
11.4. Comparison with Memcheck
SGCheck and Memcheck are complementary: their capabilities do not overlap. Memcheck performs bounds checks
and use-after-free checks for heap arrays. It also finds uses of uninitialised values created by heap or stack allocations.
But it does not perform bounds checking for stack or global arrays.
SGCheck, on the other hand, does do bounds checking for stack or global arrays, but it doesn’t do anything else.
11.5. Limitations
This is an experimental tool, which relies rather too heavily on some not-as-robust-as-I-would-like assumptions on the
behaviour of correct programs. There are a number of limitations which you should be aware of.
• False negatives (missed errors): it follows from the description above ( How SGCheck Works ) 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
SGCheck uses that as the "example" of how subsequent accesses should behave.
• False positives (false errors): similarly, and more serious, it is clearly possible to write legitimate pieces of code
which break the basic assumption upon which the checking algorithm depends. For example:
{ int a[10], b[10], *p, i;
for (i = 0; i < 10; i++) {
p = /* arbitrary condition */ ? &a[i] : &b[i];
*p = 42;
}
}
In this case the store sometimes accesses a[] and sometimes b[] , but in no cases is the addressed array overrun.
Nevertheless the change in target will cause an error to be reported.
It is hard to see how to get around this problem. The only mitigating factor is that such constructions appear very
rare, at least judging from the results using the tool so far. Such a construction appears only once in the Valgrind
sources (running Valgrind on Valgrind) and perhaps two or three times for a start and exit of Firefox. The best that
can be done is to suppress the errors.
• Performance: SGCheck has to read all of the DWARF3 type and variable information on the executable and its
shared objects. This is computationally expensive and makes 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, 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.
• Performance: SGCheck runs slower than Memcheck. This is partly due to a lack of tuning, but partly due to
algorithmic difficulties. The stack and global checks can sometimes require a number of range checks per memory
access, and these are difficult to short-circuit, despite considerable efforts having been made.
A redesign and
reimplementation could potentially make it much faster.
156