Call stack only shows top frame after restart

[oliversalzburg]

• VSCode Version: Code 1.18.1 (929bacb, 2017-11-16T18:32:36.023Z)
• OS Version: Windows_NT x64 10.0.15063
• Extensions:

Extension	Author (truncated)	Version
vscode-eslint	dba	1.4.3
EditorConfig	Edi	0.11.1
vsc-material-theme	Equ	1.1.2
JSDocTagComplete	Hoo	0.0.2
vscode-esformatter	how	1.5.2
output-colorizer	IBM	0.1.2
vscode-puglint	mrm	2.3.0
debugger-for-chrome	msj	3.5.0
code-spell-checker	str	1.5.1

(2 theme extensions excluded)

---

Lately I've been running into this issue many times per day, but I can't see the pattern that causes this.

When I hit a breakpoint, only the top stack frame is shown. More frames are displayed once I step to the next line. However, this is not possible if the line I'm breaking on is a throw statement, which makes this an annoyance.

Restarting VS Code fixes this briefly, but VS Code will start misbehaving again shortly after.

I've had this in multiple projects in various source files, so I doubt it is related to anything specific in these projects.

What can I do to gather more insights on this?

[weinand]

What version of node are you using?

[oliversalzburg]

8.9.0

[isidorn]

Here are some things which could help us track this down

1. Can you create a small reproducable sample such that we look into this on our side (probably not, right?)
2. I think you know how to run vscode out of source, put a breakpoint here and check what callstacks vscode is asking for and what it is getting back. fyi for optimazation reasons vscode should first ask for the first stack frame and then for the rest. Maybe there is an issue and vscode does not ask for the rest. Code pointer
3. Option 3 is to set logging for the node2 debugger, which @roblourens can assist with

[oliversalzburg]

Thanks for the suggestions.

1. I don't see what's causing this, so, no.
2. In theory, yes, I know how to do it. In practice, not so much. This just leads me to new problems to solve. I'm stuck on "Configured debug type 'node' is not supported." and the extension marketplace is empty in the development build.
3. Would appreciate it.

[isidorn]

Let's first go with option 3 with @roblourens
And if that does not work I can give tips on how to setup debugging on your machine so we get more details.

[oliversalzburg]

@isidorn Trying to figure it out myself right now. It's a bit confusing that verboseDiagnosticLogging is not detected as a valid setting in the launch.json, but it surely does log a lot of information.

[oliversalzburg]

After a couple of runs, I'm assuming that the additional (very noticeable) delay introduced by the verbose logging is preventing the issue from happening.

I'd really like to look into debugging the code itself, as that looks very promising from what I can tell. Is there some hacky way I could just add some logging, rebuild and put the .exe into my Program Files to replace my current stable setup or something like that?

[roblourens]

That switch is deprecated, set "trace": true and upload the file here. There should be less delay because it won't log to the console.

[oliversalzburg]

I have the same issue on my home workstation and was able to reproduce it with trace enabled. I'd rather not make the file publically available. Can I share it privately somehow?

[roblourens]

Feel free to email it to me, at the address in my profile.

[oliversalzburg]

@roblourens Done

[roblourens]

Thanks.

@isidorn The log shows only a single stackTrace request for one frame. The adapter responded with the single frame, and "totalFrames":143.

Then, requests for scopes and variables, but no additional stackTrace requests.

[isidorn]

@roblourens thanks for analysing the logs, so it seems to be an issue on the vscode side.
From my theoretical analysis of the code here it might be that vscode fetched 1 call stack, waited for 420ms as designed and in those 420ms got a clearThreads threads call which would cancel all scheduled fetchings.
This could happen by pressing step / continue. @roblourens is there something like that in the log in the 420ms window.

Unfortunetely I can not provide more help with the information I am given.
@roblourens maybe you could send me the logs on my email
@oliversalzburg if you have time maybe you could setup development vscode, place some breakpoints on the spots I gave you and setup debugging by simply copying the node-debug and node-debug2 extensions from your applicaiton into your user oss-dev folder as I explain here #20623 (comment)

[oliversalzburg]

Alright, I copied my extensions over.

When I run the Launch VS Code config, it will launch the development version of Code, but the host instance will show:

Cannot connect to runtime process, timeout after 10000 ms - (reason: Got a response from the target app, but no target pages found).

If I try to Attach to VS Code after the previous attempt launched VS Code, I get the same error message.

So I just opened the DevTools in the development build and placed the breakpoints in there, but, to no avail. When starting my application I still get:

Configured debug type 'node' is not supported.

I'm not on OSX, so the paths from #20623 were only an indication of where to look. I guess those were not the extensions I was looking for.

Alright, figured it out. Debugging now.

[oliversalzburg]

• Breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugModel.ts#L821 hit, continue
• Breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/electron-browser/rawDebugSession.ts#L344 hit, args.levels === 1

When waiting on this breakpoint for some time and then continuing, it will be hit again with 20 more stack frames and the error is not reproduced.

When not waiting, we continue

• Breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugModel.ts#L822 hit
  I can't evaluate this.schedulers.has(thread.getId()) in the console, says this is undefined.

• Breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugModel.ts#L828 is hit. So, I assume the mentioned expression evaluates to false.

• However, next a breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugModel.ts#L824 is hit, even though we never went into the previous branch.

  Makes no sense to me. Maybe it's due to working with transpiled sources. Probably, an existing scheduler is reused.

• Breakpoint on https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/electron-browser/rawDebugSession.ts#L344 hit again, args.levels === 19

No more breakpoints are hit afterwards and I see a call stack with 1 frame in the UI.

[isidorn]

@oliversalzburg thanks a lot for the investigation. @roblourens since the last breakpoint is hit it seems like vscode sends out another stackFrame request with levels 19 to get the rest of the stack frames. Is this not what you are seeing in the logs

[oliversalzburg]

Let me know if I should check anything else.

[roblourens]

@isidorn I forwarded the logs. They only show the one stackFrame request.

[oliversalzburg]

For completeness I want to mention that I did the debugging on my work workstation and the trace on my home workstation. In theory, it could be different root causes for the same problem.

If I'm unresponsive during next week, it's because I'm on a holiday. I'd be happy to pick up again afterwards if you need me.

[isidorn]

@oliversalzburg I have looked into the logs and it seems to not be related to the breakpoint investagion you did. Though I might be wrong.
Can you either of:

1. Try to get a reproducable sample which you caould share with me
2. Do a screen sharing session with me so with debug this together

Moving to decmeber since you are on vacation so no need to rush this

[oliversalzburg]

@isidorn A screen-sharing session sounds like a good idea, please get in touch via email (in my profile) so we can figure out a good time.

[oliversalzburg]

During the debugging session, we noticed that the second .stackTrace() call in getCallStackImpl is rejected with an error message of "No call stack available.".

[isidorn]

Exactly. Also @oliversalzburg is using node version 8.9.0

On the vscode side the issue is that I do not properly show the error if the second call stack returns erroniously (which I will look into fixing).
As the real issue is on the node debug side forwaridng to @roblourens
@roblourens let us know what other deatils you need as @oliversalzburg is happy to help

[oliversalzburg]

I also noticed that this behavior seems to only happen when I restart the debugging session. When I stop and start it instead, the error does not reproduce.

This also means that it apparently never happens during the initial run.

[roblourens]

I'm debugging, something weird is happening. I think vscode the debug adapter is actually not terminating correctly when using 'restart'.

[roblourens]

It also reproes with the legacy adapter. Could something have changed on the vscode side? @weinand

[weinand]

@isidorn that's in your area. Are you aware of any related changes in that area?

[roblourens]

• Debug any node app with legacy or inspector
• Run ps ax | grep nodeDebug, see one debug adapter
• Press reload
• Run ps ax | grep nodeDebug, see two debug adapters
• Stop debugging
• Run ps ax | grep nodeDebug, see one debug adapter process remaining

We are leaving the process behind after reloading. But the adapter should have shut itself down. Could be a change in the vscode-debugadapter module but I don't see anything.

[isidorn]

@roblourens great catch about multiple session lying around.
The issue was that I was for some weird reason reusing the internal debug session id for a newly restarted process. Since this is a actually a brand new session now i do not treat specially.
Not a candidate since multiple restarts only leave 1 extra session in total and this was also happening in previous stable.

@oliversalzburg you can pick up the vscode insiders from Monday if you watn your issue fixed. Thanks again for great help.

[weinand]

@roblourens You really mean "reload" and not "restart", right?
In what version of VS Code are you seeing this?

I cannot reproduce the problem of a left behind DA, neither in Stable nor in Insider (and neither "reload" nor "restart").

[oliversalzburg]

@isidorn Awesome :) Thanks everyone

[roblourens]

I guess I mean restart. I'll try with Isidor's fix.

[oliversalzburg]

@isidorn @roblourens Has there been any development regarding this issue?

[isidorn]

@oliversalzburg this issue is fixed. However it will only be availble in the next stable release (in a couple of weeks)