Re: Debugging Strategy Survey

Jim Hill <jthill@us.oracle.com>
Tue, 21 Apr 1992 07:06:01 GMT

          From comp.compilers

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)
| List of all articles for this month |
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.
--


Post a followup to this message

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