You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
Refactor so that marks_with_checkpoints is just changed in one place, not arbitrarily access it. Ref counts had the same changes in a previous commit.
Fixes a bug for loaded persistent checkpoints where the re-created checkpoints did not get their reference counting correct.
This closesrr-debugger#3678
There's currently an issue with GDB checkpoints making them behave in (probably) unintended ways.
Here's a quick run down of the behavior:
checkpoint
command)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).
The text was updated successfully, but these errors were encountered: