Description
There's currently an issue with GDB checkpoints making them behave in (probably) unintended ways.
Here's a quick run down of the behavior:
- user sets checkpoint at time T (with the
checkpoint
command) - the checkpoint is not explicit, so it will rely on an internal checkpoint at some time (T-n)
- replay continues until next stop
During the continue until next stop, the internal checkpoint at (T-n) might have been cleaned up & removed by the supervisor. If there's an internal checkpoint before it, the GDB checkpoint will restart from that instead (and if there is none before T-n
, essentially restarting that checkpoint amounts to restarting the replay from the beginning).
This is probably not the intended behavior.
This issue will be fixed by the Persistent Checkpoint
PR, because that PR requires this "searching backwards for internal checkpoints"-functionality (and has also refactored out the checkpoint refcount management, which is what keeps "internal checkpoints" alive).
So this issue will be closed by #3406 once it's done.
I came across this bug when finishing up that PR. So once I can get an "ok" that we can solve it by pulling in that PR when it's done, I'll move forward with updating the PR (rebasing onto master) - otherwise I'll have to fix this issue first (which is fine too).