This paper presents a novel technique for the automatic type identification of arbitrary memory objects from a memory dump. Our motivating application is debugging memory corruption problems in optimized, production systems — a problem domain largely unserved by extant methodologies. We describe our algorithm as applicable to any typed language, and we discuss it with respect to the formidable obstacles posed by C. We describe the heuristics that we have developed to overcome these difficulties and achieve effective type identification on C-based systems. We further describe the implementation of our heuristics on one Cbased system — the Solaris operating system kernel — and describe the extensions that we have added to the Solaris postmortem debugger to allow for postmortem type identification. We show that our implementation yields a sufficiently high rate of type identification to be useful for debugging memory corruption problems. Finally, we discuss some of the novel automated debugging mechanisms that can be layered upon postmortem type identification.
If memory corruption cannot be acceptably prevented in production code, then the focus must shift to debugging the corruption postmortem. While the notion of postmortem debugging has existed since the earliest dawn of debugging @cite_5 , there seems to have been very little work on postmortem debugging of memory corruption per se; such as it is, work on postmortem debugging has focused on race condition detection in parallel and distributed programs. The lack of work on postmortem debugging is surprising given its clear advantages for debugging production systems --- advantages that were clearly elucidated by McGregor and Malone in @cite_10 :
@cite_5 @cite_10
2020874122 2044423461
This paper describes methods developed at the Cambridge University Mathematical Laboratory for the speedy diagnosis of mistakes in programmes for an automatic high-speed digital computer. The aim of these methods is to avoid undue wastage of machine time, and a principal feature is the provision of several standard routines which may be used in conjunction with faulty programmes to check the operation of the latter. Two of these routines are considered in detail, and the others are briefly described. Program development can be greatly speeded by a dump analysis program which makes the state of a program more visible to the programmer. A single comprehensive analysis presenting as much of the relevant material in as concise a manner as possible has proved superior in use to the alternative of interactive analysis one item-at-a-time. The methods adopted in the STAB utility to achieve comprehensive and concise output are described. The system and compiler modifications necessary to support this type of system are discussed.