Skip to content

GDB Checkpoint Issue #3678

Open
Open
@theIDinside

Description

@theIDinside

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions