Difference between revisions of "Capture and replay"

Latest revision as of 09:26, 30 May 2007

This is the project page for capture & replay debugging

Overview

Capture/Replay should be implemented according to [1]:

• After defining the set of observed classes, an instrumented executable should be generated, that records all interactions between observed and unobserved objects.
• For the replay phase, unobserved classes are replaced with stubs that replay their with the observed classes based on the recorded interactions. Thus it should be possible to replay a run for the set of observed classes.

• Capture/Replay should at least be available for the Workbench (Frozen) C Code. The implementation for melted code is optional. It can't be avoided that parts of the work will depend on the compiler backend that is used. These dependencies should be isolated into separate classes and kept as small as possible.

• The overhead of capture/replay should be measured to see if it could be used in practice.

Plan

The project will be divided into several iterations to be able to work with both capture and replay as fast as possible.

iteration 0

• Basic Capture
• Basic Replay

iteration 1

• Fields
• Expanded Types
• Contracts

iteration 2

• Polymorphism
• Genericity
• Onces

iteration 3

• Agents
• Tuples
• Externals

References

[1] Shrinivas Joshi and Alessandro Orso: Capture and Replay of User Executions to Improve Software Quality

Common build errors

Here's a draft of some lessons learned while building eiffel studio:

• gcc: $ISE_EIFFEL/precomp/spec/linux-x86/EIFGENs/base/W_code/preobj.o: No such file or directory --> building of precompiles not successfully finished. Precompile $ISE_EIFFEL.

Other common errors

• console applications in debug mode can't read from console, if the hosting eiffel studio was started in the background ('estudio &' instead 'estudio'). This is no bug, as '&' detaches the application from the standard input.

Open Questions

• Why does Eiffel not support 'real' weak references? IDENTIFIED makes it necessary to modify a class before weak references to its objects are possible. Wouldn't it be possible to keep a table of Eiffel objects, which is ignored when calculating the reachable set of objects, but whose references are updated, when the GC moves objects? Instead of keeping the offset of the table entry (object_id of IDENTIFIED):
  • an entry per weak reference could be made
  • or an entry per object, but then it would be necessary to lookup in the table before creating the reference