-
Notifications
You must be signed in to change notification settings - Fork 662
Related work
rocallahan edited this page Jul 5, 2014
·
52 revisions
This page is in a somewhat disorganized state, please bear with us.
No target recompilation or VM hypervisor required.
gdb reverse debugging ("process recorder")
Process record and replay works by logging the execution of each machine instruction in the child process (the program being debugged), together with each corresponding change in machine state (the values of memory and registers).
- unclear how modification of user memory during syscalls is recorded
- unclear how process-shared memory is dealt with
- very very high overhead
- good approach for efficient replaying reverse-step et al.
Thus spake roc:
There are a few major differences between Scribe and rr:
- Scribe doesn't serialize all threads. Instead they do a bunch of work to make sure all threads can run simultaneously. This reduces overhead in some places and adds overhead in others.
- They say their approach doesn't require "changing, relinking or recompiling the kernel" but their approach has to track internal kernel state like inodes and VFS path traversal, and it's not really clear how they do that. They also say "Scribe records by intercepting all interactions of processes with their environment, capturing all nondeterminism in events that are stored in log queues inside the kernel" so my guess is they're using a kernel module. That's a pretty big negative in my view.
- Scribe doesn't use performance counters to record asynchronous events. Instead they defer signal delivery until the next time the process enters the kernel. If the process doesn't enter the kernel for a long time, they basically take a snapshot of the entire state, force the process into the kernel and restart recording --- extremely heavyweight. For some bugs, it's essential to allow async signal delivery at any program point, so I don't like Scribe's approach there.
Time-Traveling Virtual Machines
See this page.