After installation 1.28.1, my debug extension does not show the entire call stack.

[killerall]

Issue Type: Bug

After installation 1.28.1, updated from version 1.27.2, my debug extension does not show the entire "call stack".

Previous behavior (1.27.2):
The stack was fully displayed:

New behavior (1.28.1):
If the source code is not found in the folder (s) the stack item is not displayed:

My debug extension sends the following json response to the StackTrace request:

{  
  "seq":19,
  "success":true,
  "message":null,
  "request_seq":9,
  "command":"stackTrace",
  "body":{  
    "stackFrames":[  
      {  
        "id":1001,
        "source":{  
          "name":"test.tlpp",
          "path":"c:\\vscode\\tlpp-unit-test\\test\\test.tlpp",
          "sourceReference":0
        },
        "line":10,
        "column":0,
        "name":"U_MYFINAL"
      },
      {  
        "id":1002,
        "source":{  
          "name":"APLIB190.PRW",
          "path":"APLIB190.PRW",
          "sourceReference":0
        },
        "line":164,
        "column":0,
        "name":"EXECBLOCK"
      },
      {  
        "id":1003,
        "source":{  
          "name":"MSFINAL.PRW",
          "path":"MSFINAL.PRW",
          "sourceReference":0
        },
        "line":64,
        "column":0,
        "name":"FINAL"
      },
      {  
        "id":1004,
        "source":{  
          "name":"FWAPP.PRW",
          "path":"FWAPP.PRW",
          "sourceReference":0
        },
        "line":600,
        "column":0,
        "name":"{ || PSWWPCOMMIT())}"
      },
      {  
        "id":1005,
        "source":{  
          "name":"FWAPP.PRW",
          "path":"FWAPP.PRW",
          "sourceReference":0
        },
        "line":714,
        "column":0,
        "name":"{ || EVAL(BCLOSE)}"
      },
      {  
        "id":1006,
        "source":{  
          "name":"FWAPP.PRW",
          "path":"FWAPP.PRW",
          "sourceReference":0
        },
        "line":714,
        "column":0,
        "name":"ACTIVATE"
      },
      {  
        "id":1007,
        "source":{  
          "name":"APLIB000.PRW",
          "path":"APLIB000.PRW",
          "sourceReference":0
        },
        "line":123,
        "column":0,
        "name":"SIGAFAT"
      }
    ]
  },
  "type":"response"
}

Has something changed that I need to implement in my extension?

PSC
I tested the insiders and behavior continues the same as 1.28.1.

VS Code version: Code 1.28.1 (3368db6, 2018-10-11T18:13:53.910Z)
OS version: Windows_NT x64 10.0.15063

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2904)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Memory (System)	15.87GB (8.19GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (10)

Extension	Author (truncated)	Version
numbered-bookmarks	ale	0.12.0
tslint	eg2	1.0.40
advpl-vscode	Kil	0.10.12
cmake-tools-helper	mad	0.2.1
Angular-BeastCode	Mik	6.2.32
cpptools	ms-	0.19.0
debugger-for-chrome	msj	4.10.2
vscode-coverage-gutters	rya	2.2.0
cmake	twx	0.0.17
cmake-tools	vec	1.1.2

[isidorn]

@killerall thanks for reporting this issue. Does your extension supportsDelayedStackTraceLoading. If you return totalFrames as part of the StackTraceResponse does that make a difference?

@killerall For the future since you are an extension author it would be great if you could be using Insider - that way we would be able to find issue like this sooner.

fyi @weinand

[killerall]

@isidorn thanks for the answer.

I just implemented and tested the totalFrames in response. There was no difference.

I usually use the Insider, but I'm not programming in ADPVL so often. I'll ask some user keys to use the Insider as well. Thank you.

[isidorn]

Thanks. Does your extension supportsDelayedStackTraceLoading.
Does changing that capability make a difference?

If you F1 > developer tools > are there some errors in the console?
What are the argumens for the stackTrace that you recieve from vscode?

[killerall]

Thanks. Does your extension supportsDelayedStackTraceLoading.
Does changing that capability make a difference?

No.
But I found what changed.
f8a736c#diff-05910b80b38cefe548a9d4f9c9d6c78e

In the latest version of Uri.ts, it throws exceptions if it can not find the file.

The getCallStackImpl method of the debugModel.ts class stops adding the elements in the stack if any exceptions are thrown.

	private getCallStackImpl(startFrame: number, levels: number): TPromise<IStackFrame[]> {
		return this.session.stackTrace(this.threadId, startFrame, levels).then(response => {
			if (!response || !response.body) {
				return [];
			}


			if (this.stoppedDetails) {
				this.stoppedDetails.totalFrames = response.body.totalFrames;
			}


			return response.body.stackFrames.map((rsf, index) => {
				const source = this.session.getSource(rsf.source);


				return new StackFrame(this, rsf.id, source, rsf.name, rsf.presentationHint, new Range(
					rsf.line,
					rsf.column,
					rsf.endLine,
					rsf.endColumn
				), startFrame + index);
			});
		}, (err: Error) => {
			if (this.stoppedDetails) {
				this.stoppedDetails.framesErrorMessage = err.message;
			}


			return [];
		});
	}

[isidorn]

@killerall great find!
@weinand can you maybe look into this since you are already in URI land?
I would assume here is the issue https://github.com/Microsoft/vscode/blob/d08e54002bf38b0f584ec39a16af92fe923538cb/src/vs/workbench/parts/debug/common/debugSource.ts#L55

[weinand]

The new URI.parse behaviour in VS Code 1.28.1 results in an exception if the "path" attribute of a "Source" is not absolute.

I've added a workaround to restore the previous behaviour.

However, returning relative paths in a "Source" object and having a "sourceReference" with value 0 at the same time does not make any sense.

@killerall here is the explanation:

• VS Code can only match absolute "Source.path" values against workspace files. Relative paths are not supported because VS Code has no notion of a "current directory" against the relative path can be applied.
• a relative "Source.path" can only be provided (e.g. for display purposes) if it is accompanied by a "Source.sourceReference" > 0. In this case VS Code uses the "sourceReference" to retrieve the contents of the source from the debug adapter.

So all but the first "Source" objects in the json response from above are incorrect because they have relative paths and a "sourceReference" of 0.

[killerall]

@weinand Thanks for the answer.
I did not understand the sourceReference correctly.
In the following stack example:

function1 - Source1
function2 - Source2
function3 - Source1

Let's assume that the Source2 source file is not in the workspace. Should I return a SourceResponse with blank content?

If this is the correct behavior, I will change my extension.

[weinand]

This is a correct source object because "path" is absolute:

        "source":{  
          "name":"test.tlpp",
          "path":"c:\\vscode\\tlpp-unit-test\\test\\test.tlpp",
          "sourceReference":0
        },

This source object is incorrect because "path" is relative:

        "source":{  
          "name":"APLIB190.PRW",
          "path":"APLIB190.PRW",
          "sourceReference":0
        },

Let's assume that the Source2 source file is not in the workspace. Should I return a SourceResponse with blank content?

The easiest fix is to make "path" absolute by adding the containing folder to the path.
This applies to both files in the workspace and files outside of it.

So something like this:

        "source":{  
          "name":"APLIB190.PRW",
          "path":"c:\\vscode\\tlpp-unit-test\\test\\APLIB190.PRW",
          "sourceReference":0
        },

VS Code will load files in both cases.
If you can always provide absolute paths you don't have to deal with "sourceReferences" (and the "source" request) at all.

Use a "sourceReference" only if there is no local file behind a "source" object. In that case your DA can manufacture the contents and return it from the source request.

[killerall]

@weinand Thank you very much for the quick reply.

The problem is the source code APLIB190, for example, is not available in the workspace, and DA does not know it either (similar to a dynamic library that does not have the source code).

If I could understand. I should send sourceReference (in APLIB090), and when DA receives the request, I return the content as: "source code is not available".

This is correct?

[weinand]

@killerall yes, your approach is basically correct.

But please consider this: even if the source is not available in your workspace (or outside), there is probably a binary file (e.g. a dynamic library) somewhere in the filesystem. And this file has a path. In this case I recommend to return that path. VS Code will automatically show an error if it cannot show the contents of the file in an editor.

[killerall]

Understood.
Thank you very much for your attention.
I will change as soon as possible.

[weinand]

@killerall it would be great if you could verify that your (unmodified) debug extension works as before in the latest Insiders.

[killerall]

@weinand
I tested it and it worked perfectly.

Thanks a lot.

[weinand]

Great, I'll add a verified label.