NEW Debugging extension & lsp server issues

[eamodio]

Issue Type: Bug

Starting in today's insiders build, I'm running into lots of issues when debugging my extension and attaching to its associated lsp server.

First when debugging the extension and attached to the lsp server, it causes the debugging drop down to contain a duplicate item for the extension:

Also when debugging the extension and attached to the lsp server, the call stack for the lsp server doesn't even show up anymore.

I've also seen other issue where stepping over or into a function, just basically runs rather than stepping, but I can't pin that down as it doesn't happen all the time - unlike the issues above.

//cc @isidorn

VS Code version: Code - Insiders 1.29.0-insider (931c220, 2018-10-12T05:17:15.739Z)
OS version: Windows_NT x64 10.0.18252

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 x 4008)
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)	31.93GB (16.52GB free)
Process Argv	c:\Users\Eric\code\vscode-gitlens
Screen Reader	no
VM	0%

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• console.[log|info|debug] from a LSP client is no longer logged (#57308)

[isidorn]

@eamodio thanks for creating this issue.
I tried reproducing with a simple out of the box vscode extension and I could not.
I tried to find the extension you are showing in your screenshots on GitHub but I coudl not.
If I start a similar compound with launch & attach like the Debug VSCode main and renderer from this repo I can not reprodcude.
My point is can you share some repository for which these issues can be reproduced? I believe that there is an issue caused by my session refactoring done for the multiple debug consoles.

Step over continues instead of steps sounds like an old node issue @weinand would know better

[eamodio]

@isidorn unfortunately the projects aren't currently open source. Is there other logging or something I can provide? Or can you point me where to look in the code to try to debug?

[isidorn]

@eamodio let's first try to figure out why there are duplicated sessoins in the dropdown
F1 > developer tools > source > put a breakpoint here
Verify that he ends up having 3 sessions instead of 2 becuase none of them are INACTIVE - I believe that is the bug.

In case the above really happens, we need to figure out why the shutdown was not called, since it would set the raw to undefined, thus making the session inactive. For that I would put a breakpoint here

Other issues might be coming from this one, so let's first fix it.

[eamodio]

@isidorn I debugged it a bit -- and see that when I start the first debugging session (before the attach) there are 2 sessions in that array -- and they are identical references this.sessions[0] === this.sessions[1] is true, and when I start the attach there are 3, 2 dupes and a new attach.

[eamodio]

@isidorn it looks like the issue is after the debug session starts an EXTENSION_ATTACH_BROADCAST_CHANNEL event is fired here:

https://github.com/Microsoft/vscode/blob/9e83209ed59a22df3d593735d04cc963396bb89e/src/vs/workbench/parts/debug/electron-browser/debugService.ts#L145-L151

Which then re-adds the same session again.

[isidorn]

@eamodio thanks a lot for investigating, really appreciate it.
The way Extension host debugging is designed it is expected that a session is re-initialized and thus being re-added to the model.
Anyways I have pushed a minor fix which makes sure it de-dups session in the model after they are added.
Andre also fixed some uri issues, so it would be great if you can check the behavior in the next insiders on Friday and let us know if there are still issues you are seeing. Thanks

[eamodio]

@isidorn Sweet -- debugging is working again!

[isidorn]

Great, thanks for letting us know it is good and for filling great issues.
Adding verified label

[eamodio]

I should also note that I was able to fix my issues with stepping (i.e. not stepping just running each time I tried to step in or over) by switching my webpack config to use source-map rather than eval-source-map for its devtool setting. While its a bit slower to build, its a far better debugging experience -- though I'm not sure what changed as eval-source-map used to work with stepping

[isidorn]

@roblourens @weinand fyi regarding last comment