Support saving and loading checkpoints to/from hard disk
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.7k
- Forks
- 662
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 2
Description
This feature request was inspired by a scenario in which I had to debug an application where the bug occurs after a long time into the execution (in my example 20 minutes). I figured out the exact event number (around 600 000). Each time when I want to start debugging, I start rr with -g 600000 and go grab a cup of coffee until the application execution reaches the interesting event. Once rr reaches this event, I can normally use forward and backward execution for debugging. The kicker is, I can always restart to the interesting event with run 600000, and I won't have to wait for long because rr can intelligently rewind to this event.
The feature request is the following: could I save the state of the application at the 600 000th event to a snapshot, and tell rr to load that snapshot on startup, instead of waiting for rr to run the application from beginning?
Better yet, rr could maintain a list of saved snapshots in a trace, and automatically choose the closest one when run is called, in order to minimize the time that the user will have to wait for the execution to reach that event. The workflow would look something like this:
# this takes 20 minutes
$ rr record app
# this also takes 20 minutes
$ rr replay -g 600000
(rr) save snapshot
Created snapshot at event 600000.
(rr) quit
# this time rr figures out that it has a snapshot,
# so this is more or less instantaneous
$ rr replay -g 600000
# ...do debugging...
(rr) quit
# The next time we start a debugging session, we decide
# to go a little further in time:
$ rr replay -g 650000
# this is also significantly faster, because rr chooses
# the nearest snapshot (in this case 600000), and replays
# from there
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing rr replay, run, and reverse-execution workflows described in the request, then identify where replay state could be saved and restored. Done means a recorded trace can create persistent snapshots, load one on startup, and select the nearest snapshot for later run targets such as events 600000 and 650000.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100