Abstract
When a program failure occurs, the cause of that failure cannot always be found in the reached state of the program. Back-in-time debuggers address this issue by storing information about the program's execution history, but face challenges where performance and scalability are concerned.
Our approach is restricted to systems of state machines. The transitions can execute at nearly full speed since we merely save data from one state machine after each transition. Our debugger offers a model-level view of the running system, dealing with transitions and signal passing rather than individual code statements.
We offer empirical data on time and space overheads and we have evaluated the usability of our debugger on a set of students in a course with UML modelling. And we discuss the problems associated with reverting the state of a system during runtime.
When a program failure occurs, the cause of that failure cannot always be found in the reached state of the program. Back-in-time debuggers address this issue by storing information about the program's execution history, but face challenges where performance and scalability are concerned.
Our approach is restricted to systems of state machines. The transitions can execute at nearly full speed since we merely save data from one state machine after each transition. Our debugger offers a model-level view of the running system, dealing with transitions and signal passing rather than individual code statements.
We offer empirical data on time and space overheads and we have evaluated the usability of our debugger on a set of students in a course with UML modelling. And we discuss the problems associated with reverting the state of a system during runtime.