Re: Suggestions for C malloc debugging tool

Joerg Schoen writes:
[ suggest instrumenting C source with pointer validity checking code]


As part of my Ph.D. thesis at UW-Madison I had developed such a C to C
translator for pointer and array access checking using a technique
called "guarding". I had also done a detailed comparison of our
translator with "Purify". A paper based on "guarding" appears in this
month's `Software -- Practice and Experience'. I am enclosing an
abstract of the paper below.


Regards,


-Harish
-------------------------------------------------------------------
  "Low-cost, Concurrent Checking of Pointer and Array Accesses in C
  Programs": Harish Patil and Charles Fischer; Software-Practice and
  Experience, Vol. 27(1), 87-110 (January 1997).


  Abstract:
  ---------
Illegal pointer and array accesses are a major cause of failure for C
programs. We present a technique called "guarding" to catch illegal
array and pointer accesses. Our implementation of guarding for C
programs works as a source-to-source translator. Auxiliary objects
called guards are added to a user program to monitor pointer and array
accesses at run time. Guards maintain attributes to catch out of
bounds array accesses and accesses to deallocated memory. Our system
has found a number of previously unreported errors in widely-used Unix
utilities and SPEC92 benchmarks.


Many commonly used programs have bugs which may not always manifest
themselves as a program crash but may instead produce a subtly wrong
answer. These programs are not routinely checked for run-time errors
because the increase in execution time due to run-time checking can be
very high. We present two techniques to handle the high cost of
run-time checking of pointer and array accesses in C programs: 1)
"customization" and 2) "shadow processing". Customization works by
decoupling run-time checking from original computation. A user
program is customized for guarding by throwing away computation not
relevant for guarding. We have explored using program slicing for
customization. Customization can cut the overhead of guarding by up to
half. Shadow processing uses idle processors in multiprocessor
workstations to perform run-time checking in the background. A user
program is instrumented to obtain a "main process" and a "shadow
process." The main process performs computations from the original
program, occasionally communicating a few key values to the shadow
process. The shadow process follows the main process, checking pointer
and array accesses. The overhead to the main process which the user
sees is very low - almost always less than 10%.


==========================================================================
Harish Patil: Massachusetts Language Lab - Hewlett Packard
Mail Stop CHR02DC, 300 Apollo Drive, Chelmsford MA 01824
Phone: 508 436 5717 Fax: 508 436 5135 Email: patil@apollo.hp.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.