Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clearly spell out the lifetime of IDs used in the protocol #60

Closed
weinand opened this issue Jun 24, 2019 · 4 comments
Closed

clearly spell out the lifetime of IDs used in the protocol #60

weinand opened this issue Jun 24, 2019 · 4 comments
Assignees
Labels
clarification Protocol clarification

Comments

@weinand
Copy link
Contributor

weinand commented Jun 24, 2019

The general rule for ID lifetime in DAP is:

  • IDs of "ephemeral" objects are valid while in the stopped state (or as Gregg said: "until the next 'continue'"). Examples are variable references, goto targets, step-in target, frames.
  • IDs of long living objects are valid at least for the lifetime of the debug session (e.g. processes, threads), or even longer (breakpoints, data breakpoints).

This should be more clearly spelled out in the protocol.

@weinand weinand added the clarification Protocol clarification label Jun 24, 2019
@weinand weinand self-assigned this Jun 24, 2019
@weinand weinand added this to the June 2019 milestone Jun 24, 2019
@weinand weinand changed the title clearly spell out the lifetime of the GotoTarget IDs clearly spell out the lifetime of the IDs Jun 24, 2019
@weinand weinand changed the title clearly spell out the lifetime of the IDs clearly spell out the lifetime of IDs used in the protocol Jun 24, 2019
@int19h
Copy link

int19h commented Apr 9, 2020

If we see a sequence of messages from VSCode that does not follow these guidelines - e.g. an attempt to do an "evaluate" immediately after sending "next" (which invalidated all frame IDs, and so the one that comes in "evaluate" is no longer valid), is that a client bug? If so, where should it be filed?

@weinand
Copy link
Contributor Author

weinand commented Apr 14, 2020

yes, I that's a client bug.

@isidorn but it's tricky for the client to figure this out, correct?

@isidorn
Copy link

isidorn commented Apr 14, 2020

Yeah it is a bit tricky, since we do some ui optimisations (e.g we refresh the watch element with a slight timeout and thus it can happend that you get a stale evaluate).
However an issue is welcome, and you can file it here https://github.com/microsoft/vscode and feel free to ping me @isidorn on the issue

@weinand
Copy link
Contributor Author

weinand commented Nov 16, 2022

/duplicate #35

@weinand weinand closed this as completed Nov 16, 2022
@weinand weinand removed this from the June 2019 milestone Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Protocol clarification
Projects
None yet
Development

No branches or pull requests

3 participants