Related articles |
---|
Debugging Strategy Survey yoshi@cs.washington.edu (1992-03-31) |
Re: Debugging Strategy Survey jxyb@crystal.lanl.gov (1992-04-02) |
Re: Debugging Strategy Survey jthill@us.oracle.com (Jim Hill) (1992-04-21) |
Newsgroups: | comp.compilers |
From: | Jim Hill <jthill@us.oracle.com> |
Keywords: | debug |
Organization: | Oracle Corporation, Belmont, CA |
References: | 92-04-004 |
Date: | Tue, 21 Apr 1992 07:06:01 GMT |
yoshi@cs.washingto.edu writes:
>I'm doing a survey on methods programmers utilize in dealing with bugs
>caused due to non-local dependencies.
The method I know best is to implement an internal trace -- a circular
array of entries describing *every* global-state transition that might
matter. Put wrappers on allocation, locks, message passing, cache loads/
spills, queues, async dispatch/exit... Make the in-core trace entries
semi-usable in a dump by putting an eyecatcher at the front of each and
making the union size match the number of bytes your dump formatter prints
on a line or two. Then in the wrappers fill out a local trace entry and
pass its address to the tracer, which copies it to the next entry in the
circular array. Leave the traces in and turned on, always. When your
program detects something seriously wrong, just dump core. If (since)
you're juggling multiple units of work, don't forget to have some way of
determining the guilty party for each entry, and trace the initiation and
completion of each. Force a few dumps in perfectly good situations so you
know what normal behavior looks like, and try to reconstruct exactly what
happened from the trace. If you can't, or feel you got lucky, figure out
what's missing and trace that.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.