Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site eosp1.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!harpo!ulysses!princeton!eosp1!robison
From: robison@eosp1.UUCP (Tobias D. Robison)
Newsgroups: net.ai
Subject: Re: Expert systems for software debugging?
Message-ID: <531@eosp1.UUCP>
Date: Wed, 18-Jan-84 09:59:45 EST
Article-I.D.: eosp1.531
Posted: Wed Jan 18 09:59:45 1984
Date-Received: Thu, 19-Jan-84 04:48:41 EST
References: <15616@sri-arpa.UUCP>
Organization: Exxon Office Systems, Princeton, NJ
Lines: 27

There is a good possibility in this area.  One of the toughest kinds of
debugging is to read a dump of a program that crashed, looking for
bad data, and trying to make associations to explain what caused the
data to go bad.  A computer program should be able to work
interactively with a person to try out hypotheses like these on
memory areas containing incorrect data:

- what kind of garbge is this? (e.g., ascii, floating point,
instructions,  intermediate output from part of this program,
the kind of data produced by the linking loader, etc.)

- what kind of software errors can allow this kind of overwrite to
occur? (pointer error, overflowing array boundaries, etc.)

- what similarity is there between this dump and the last one?

- what parts of the dump can be ignored, so the human can concentrate
on the problem areas?

A good programmer does this kind of analysis by calling upon his
pattern matching, experience of crashes, and knowledge of data types.
Although a compuiter will be deficient in all these areas, it will
excel the human in its ability to examine many data items tirelessly.
				  - Toby Robison
			          decvax!ittvax!eosp1!robison
				  or:   allegra!eosp1!robison
				  (maybe: princeton!eosp1!robison)