[debug] Source.adapterData is not preserved across debug sessions

[vadimcn]

• VSCode Version: 1.16.1
• OS Version: All

The StackFrame.source.adapterData attribute that adapter sends to the client, does not round-trip to SetBreakpointsArguments.source.adapterData across debug sessions. However, protocol documentation states that it should be preserved (or at least that's how I read it).

[isidorn]

@vadimcn my assumption is that here we do not find a source so we just create a new object. Can you set a breakpoint and verify is that is happening?

In order to reproduce this issue on my machine better, can you clarify your steps? Can you reproduce this only if debugging is stopped and started again - thus you mention across debug sessions?
Also can you reproduce with latest insiders as @weinand has improved how we handle source uris.

[vadimcn]

my assumption is that here we do not find a source so we just create a new object. Can you set a breakpoint and verify is that is happening?

Yes, that's what seems to be happening.

In order to reproduce this issue on my machine better, can you clarify your steps?

So I'm allowing to set breakpoints in generated sources (disassembly). In order to reconstitute breakpoints across debug sessions, I need to remember how source lines mapped to addresses. I was trying to stash this info into 'adapterData', but it gets preserved only during debug session. If I stop and restart debugging, it is lost.

Also can you reproduce with latest insiders as @weinand has improved how we handle source uris.

No, insiders build does not seem to be better in this respect.

[isidorn]

@vadimcn thanks for reporting this. There was an issue that we were not preserving adapterData across sessions, due to the lifecycle of a session on our end. Now we tie the adapterData to the breakpoint, so it should survive between sessions.
Please try out the insiders from Monday and let us know if the issue is fixed for you. Thank you

[vadimcn]

@isidorn: This still isn't working in 9/25 insiders build.

[isidorn]

@vadimcn there are no new insiders builds due to failed signing for a couple of days. Please download insiders manualyy from here and try it out. Not sure what is your platform, here's bunch
https://az764295.vo.msecnd.net/insider/a5210bcbda97166904ce4c08ee296cb98fccfcd9/VSCodeSetup-x64-1.17.0-insider.exe
https://az764295.vo.msecnd.net/insider/a5210bcbda97166904ce4c08ee296cb98fccfcd9/VSCodeSetup-ia32-1.17.0-insider.exe
https://az764295.vo.msecnd.net/insider/a5210bcbda97166904ce4c08ee296cb98fccfcd9/VSCode-darwin-insider-unsigned.zip
https://az764295.vo.msecnd.net/insider/a5210bcbda97166904ce4c08ee296cb98fccfcd9/code-insiders-1.17.0-1506403208.el7.x86_64.rpm

[vadimcn]

@isidorn: I did install an upgrade yesterday and Help/About said "Date 2017-09-25...".

Installed another update today... looks like something got broken, because adapterData is no longer preserved even within the same debug session for setBreakpoints (for source request it is preserved).

Help/About:

Version 1.17.0-insider
Commit a5210bcbda97166904ce4c08ee296cb98fccfcd9
Date 2017-09-26T05:15:18.286Z
Shell 1.7.7
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

[isidorn]

@vadimcn thanks for letting me know, reopening to investigate

[isidorn]

@vadimcn pushed a fix, please try it out in tomorrows insiders (not yet out). What os are you using, so I know what link to give you

[vadimcn]

I'm on a 64 bit Ubuntu

[isidorn]

@vadimcn https://az764295.vo.msecnd.net/insider/9fe72c0a2e50b405b466aad89ebd3c16ff8f8de0/code-insiders_1.17.0-1506585531_amd64.deb

Let us know how it goes

[vadimcn]

@isidorn: Nope, adapterData still does not survive across debug sessions.
The path property does persist though. Maybe I could encode my data there? Can path be a URI?

[weinand]

@vadimcn Yes, in the Insiders a "Source.path" can be a URI.

[weinand]

@vadimcn please provide some details about where the adapterData is lost.

[vadimcn]

It seems that adapterData is lost when the debug session ends:

• I emit adapterData (along with name and sourceReference) when responding to stackTrace request.
• I get it back when VSCode requests source for that stack frame.
• I get it back in setBreakpoints request when I set a breakpoint in that source file.
• However, I don't get it back after stopping and re-starting debugging. The source field in setBreakpoints request contains just name and path from the previous session (path being equal to name, btw, which is a bit strange).

[isidorn]

@vadimcn thanks for providing more details.
Currently the adapterData lacks a bit of documentatoin. It was intended only to be used with source that lives in a breakpoint and the implemention follows this.
In order for the adapterData to be stored across seasion you would need send that adapterData to a source that is tied to a breakpoint.
You can do this using a Breakpoint 'changed' event, or simply by responding to the intial breakpoint request with the correct source with the adapter data.

If you simply tie the adapter data to the source it will not be persisted due to the different lifecycle of a breakpoint and a source on the implementation side.

I understand this might be a bit complex, so as an alterantive you could also encode this data in the uri.

[vadimcn]

@isidorn: Are the sources stored with breakpoints completely separate from sources VSCode stores for files? Will it try to re-associate them? If so, which attribute will be used to group them together?

[isidorn]

@vadimcn it will try to reasociate them, we always use uri as an identifier. And here is how we contruct the uri for an internal debug source https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugSource.ts#L28

We do not store the whole source object with the breakpoint, nor do we store the source object anywhere since their lifecycle is the same as the lifecycle of a debug session, so they always come new when a debug session starts. We only store the adapterData with the breakopint which is a bit ugly imho.