Many programmers have had to deal with an overwritten variable resulting for example from an aliasing problem. The culprit is obviously the last write-access to that memory location before the manifestation of the bug. The usual technique for removing such bugs starts with the debugger by (1) finding the last write and (2) moving the control point of execution back to that time by re-executing the program from the beginning. We wish to automate this. Step (2) is easy if we can somehow mark the last write found in step (1) and control the execution-point to move it back to this time. In this paper we propose a new concept, position, that is, a point in the program execution trace, as needed for step (2) above. The position enables debuggers to automate the control of program execution to support common debugging activities. We have implemented position in C by modifying GCC and in Java with a bytecode transformer. Measurements show that position can be provided with an acceptable amount of overhead.
@cite_17 , Moher @cite_8 and @cite_15 save complete memory history of process to achieve fully random accessibility to program states. Their systems have to deal with large log''. Our system, however, saves only a pair of line number and value of timestamp to obtain the same capability by assuming the determinism of debuggees.
@cite_8 @cite_15 @cite_17
2153838924 2060071172 2082498963
The author introduces PROVIDE, a source-level process visualization and debugging environment currently under development at the University of Illinois at Chicago. PROVIDE is a modern coding and debugging environment that is designed to allow the user to configure interaction at a desired level of abstraction. It emphasizes the use of interactive computer graphics for the illustration of program execution, with special attention to the requirements of program debugging. The major features of PROVIDE are presented, especially the concepts of deferred-binding program animation, which allows users to interactively change the depiction of program execution during the debugging task, and process history consistency maintenance, which guarantees a consistent (automatically updated) record of program execution in the face of changes to program instructions and run-time data values. The current PROVIDE prototype is implemented on Macintosh workstations networked to a VAX 11 780 running 4.2 BSD Unix. > Demonic memory is a form of reconstructive memory for process histories. As a process executes, its states are regularly checkpointed, generating a history of the process at low time resolution. Following the initial generation, any prior state of the process can be reconstructed by starting from a checkpointed state and re-executing the process up through the desired state, thereby exploiting the redundancy between the states of a process and the description of that process (i.e., a computer program). The reconstruction of states is automatic and transparent. The history of a process may be examined as though it were a large two-dimensional array, or address space-time , with a normal address space as one axis and steps of process time as the other. An attempt to examine a state that is not physically stored triggers a “demon” which reconstructs that memory state before access is allowed. Regeneration requires an exact description of the original execution of the process. If the original process execution depends on non-deterministic events (e.g., user input), these events are recorded in an exception list , and are replayed at the proper points during re-execution. While more efficient than explicitly storing all state changes, such a checkpointing system is still prohibitively expensive for many applications; each copy (or snapshot ) of the system's state may be very large, and many snapshots may be required. Demonic memory saves both space and time by using a virtual copy mechanism. (Virtual copies share unchanging data with the objects that they are copies of, only storing differences from a prototype or original [MiBK86].) In demonic memory, the snapshot at each checkpoint is a virtual copy of the preceding checkpoint's snapshot. Hence it is called a virtual snapshot . In order to make the virtual snapshot mechanism efficient, state information is initially saved in relatively large units of space and time, on the order of pages and seconds, with single-word single-step regeneration undertaken only as needed. This permits the costs of indexing and lookup operations to be amortized over many locations. Typical debugging tools are insufficiently powerful to find the most difficult types of program misbehaviors. We have implemented a prototype of a new debugging system, IGOR, which provides a great deal more useful information and offers new abilities that are quite promising. The system runs fast enough to be quite useful while providing many features that are usually available only in an interpreted environment. We describe here some improved facilities (reverse execution, selective searching of execution history, substitution of data and executable parts of the programs) that are needed for serious debugging and are not found in traditional single-thread debugging tools. With a little help from the operating system, we provide these capabilities at reasonable cost without modifying the executable code and running fairly close to full speed. The prototype runs under the DUNE distributed operating system. The current system only supports debugging of single-thread programs. The paper describes planned extensions to make use of extra processors to speed the system and for applying the technique to multi-thread and time dependent executions.