Debugger: On stopping event, Code does display any source location if top stack frame does not have source information.

[chuckries]

The issue: If the top stack frame does not have source information, the debugger fails to show a current location (even if another stack frame does have source information).

I came across this issue while using the new C# debugger for .NET Core: https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp

In C#, when stopping on an unhandled exception, the top stack frame is often in "non-user code" and the frame is either "[external code]" or a frame in OS code that the user will not have source info for. Example:

In this file, I found that when the debugger receives a stopping event, it is hard coded to set the 0th frame as the current frame:

this.setFocusedStackFrameAndEvaluate(callStack[0]);
this.openOrRevealEditor(callStack[0].source, callStack[0].lineNumber, false, false).done(null, errors.onUnexpectedError);

Prior to calling setFocusedStackFrameAndEvaluate or openOrRevealEditor, the debugService should walk it's callstack looking for a frame that has valid source information. The first frame it finds should be passed to setFocusedStackFrameAndEvaluate and openOrRevealEditor.

Additionally: I found that if a debugAdapter does not provide source information for a frame, VS Code creates a default Source object for the stack frame:

return new StackFrame(data.threadId, rsf.id, rsf.source ? new Source(rsf.source) : new Source({ name: 'unknown' }), rsf.name, rsf.line, rsf.column);

This issue is that a default Source objects sets source available to true:

    constructor(public raw: DebugProtocol.Source) {
        this.uri = raw.path ? uri.file(raw.path) : uri.parse(Source.INTERNAL_URI_PREFIX + raw.name);
        this.available = true;
    }

I believe that if a debugAdapter does not provide source for a frame, VS Code should not mark a stack frame as having source available.

[chuckries]

@weinand

[weinand]

@chuckries If a stack frame does not have source information, the debugger UI cannot "infer" a location from some other frame by "walking its callstack looking for a frame that has valid source information". That would be too much guessing in a language agnostic UI.
So if you need this behaviour, just implement it in the debug adapter.

From your screenshot I do not really understand what is the problem because I only see the name of the frame?

@isidorn could you please look into the issue of "default Source objects sets source available to true"

[chuckries]

The issue is that when the exception goes unhandled and the debugger stops, it does not set the current location.

In this image I have just stopped but I do not know where I am.

After selecting the ConsoleApplication.... frame it looks like this:

I believe that the location seen in the second screenshot should be the behavior when the debugger stops on the exception. The debug adapter should not control this sort of UI feature. It simply hands back a callstack. It is up to the UI to determine from those stack frames which should be set as the active frame. If there is no source info availalbe in frame[0], but there is source info available in frame[1], why would the debugger not set frame[1] as the active frame with the green arrow? The green arrow signifies that this is the current source location for the active frame, but it is not the current IP.

[weinand]

I still cannot see the relevant information in your stackframes.
Could you try to make the Call Stack viewlet wider so that we can see the right hand side of it.
Like this:

“The debug adapter should not control this sort of UI feature.”

This is not really true.
The debug adapter is an adapter between a debugger API and the VS Code debugger UI.
The VS Code debug protocol is a protocol for serving the VS Code debugger UI (and nothing else). It is not a protocol for serving any other tool.
The VS Code debugger UI is debugger and language agnostic, that means that the debug adapter has to control how types, values and the structure of variables is presented in the UI. The same is true for other areas of the protocol.