STEINBERG@RUTGERS.ARPA (01/19/84)
From: Lou <STEINBERG@RUTGERS.ARPA> I don't know of any serious work in AI on software debugging since HACKER. HACKER was a part of the planning work done at MIT some years ago - it was an approach to planning/automatic programming where planning was done with a simple planner that, e.g., ignored interactions between plan steps. Then HACKER ran the plan/program and had a bunch of mini-experts that detected various kinds of bugs. See Sussman, A Computer Model of Skill Acquisition, MIT Press, 1975. Also, there is some related work in hardware debugging. Are you aware of the work by Randy Davis at MIT and by Mike Genesereth at Stanford on hardware trouble shooting? This is the problem where you have a piece of hardware (e.g. a VAX) that used to work but is now broken, and you want to isolate the component (board, chip, etc.) that needs to be replaced. Of course this is a bit different from program debugging, since you are looking for a broken component rather than a mis-design. E.g. for trouble shooting you can usually assume a single thing is broken, but you often have multiple bugs in a program. Here at Rutgers, we're working on an aid for design debugging for VLSI. Design debugging is much more like software debugging. Our basic approach is to use a signal constraint propagation method to generate a set of possible places where the bug might be, and then use various sorts of heuristics to prune the set (e.g. a sub-circuit that's been used often before is less likely to have a bug than a brand new one).