This is an archive of the discontinued LLVM Phabricator instance.

[lldb-vscode] Added support for ‘totalFrames’ field in StackTraces response
ClosedPublic

Authored by serhiy.redko on Dec 4 2019, 2:41 PM.

Details

Reviewers
lanza
clayborg
Summary

The field ‘totalFrames’, total number of frames available, is mandatary in StackTraces response for VSCode extension that implements DAP and declares capability 'supportsDelayedStackTraceLoading':

"The debug adapter supports the delayed loading of parts of the stack,
which requires that both the 'startFrame' and 'levels' arguments and the
'totalFrames' result of the 'StackTrace' request are supported."

Lack of this field makes VSCode incorrectly display stack traces information

Diff Detail

Event Timeline

serhiy.redko created this revision.Dec 4 2019, 2:41 PM
serhiy.redko edited the summary of this revision. (Show Details)
lanza added a comment.Dec 5 2019, 1:23 PM

LGTM. Any concerns @clayborg?

I seems this is optional in https://microsoft.github.io/debug-adapter-protocol/specification

interface StackTraceResponse extends Response {
  body: {
    /**
     * The frames of the stackframe. If the array has length zero, there are no stackframes available.
     * This means that there is no location information available.
     */
    stackFrames: StackFrame[];

    /**
     * The total number of frames available.
     */
    totalFrames?: number;
  };
}

It is nice to not have to send this back because if you have 300,000 stack frames due to a stack overflow, it can take quite a while to count up all 300,000 frames just so we can tell the DAP this large number. Where did you see this was mandatory?

clayborg accepted this revision.Dec 5 2019, 4:39 PM

If this does make things not behave correctly, we should add it in, I don't have any problem with it since most of the time we won't have that many stack frames.

This revision is now accepted and ready to land.Dec 5 2019, 4:39 PM
serhiy.redko added a comment.EditedDec 5 2019, 5:54 PM

Thanks @clayborg ,

Basically I also was confused with that field which is marked as optional in schema and initially I thought this is VSCode UI issue that expects that field to be present for DAP implementations that provide support for 'supportsDelayedStackTraceLoading' capability.
Then I read the following in specification for 'supportsDelayedStackTraceLoading' and concluded that for DAP that supports 'supportsDelayedStackTraceLoading', 'totalFrames' field is mandatory.

/**
  * The debug adapter supports the delayed loading of parts of the stack, which requires that both the 'startFrame' and 'levels' arguments and the 'totalFrames' result of the 'StackTrace' request are supported.
  */
 supportsDelayedStackTraceLoading?: boolean;

Please let me know if you are disagree and with your appropriate arguments I can submit/fix issue in VSCode.

lanza closed this revision.Dec 18 2019, 4:31 PM

This was landed.

No worries. Large large stacks are rare and I would rather backtraces work correctly in the IDE if the schema was wrong. Sorry for the delay, medical issues for the past few months on my end.