New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to attach to lsp server when debugging extension #63832

Closed
eamodio opened this Issue Nov 27, 2018 · 24 comments

Comments

Projects
None yet
7 participants
@eamodio
Copy link
Contributor

eamodio commented Nov 27, 2018

Issue Type: Bug

This started relatively recently and only affects the insiders builds, but I can no longer attach to my lsp server when debugging my extension. When I try the attach just times out. If I switch back to the stable build (1.29.1) everything works fine.

image

Unfortunately the project is currently closed-source, so I can't provide a good reproducible case. Let me know if I can provide any other details.

/cc @isidorn

VS Code version: Code - Insiders 1.30.0-insider (456e8e6, 2018-11-26T11:05:14.406Z)
OS version: Windows_NT x64 10.0.18282

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.64GB free)
Process Argv
Screen Reader no
VM 0%

@vscodebot vscodebot bot added the insiders label Nov 27, 2018

@vscodebot

This comment has been minimized.

Copy link

vscodebot bot commented Nov 27, 2018

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

@isidorn

This comment has been minimized.

Copy link
Contributor

isidorn commented Nov 27, 2018

Assigning first to @weinand and @roblourens to investigate why the attach times out

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Nov 27, 2018

Most likely the lsp server did not start in debug mode. Can you get anything if you open localhost:6009 in a browser?

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 27, 2018

Hrm, I don't think that is the case. This is the same workflow as I've been using for months and using exactly the same code and setup prior to a week or so ago this all worked fine. Also if I switch to the 1.29.1 running against the exact same workspace, build, etc it all works fine.

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Nov 28, 2018

I can't repro it with https://github.com/Microsoft/vscode-extension-samples/tree/master/lsp-sample, can you? Can't think of anything that changed on my end.

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

I can repro with that repo too. Here is what I see in the Debug Output:

image

Again this works fine in 1.29.1. I am also on Windows 10

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

This is what I see in the browser with 1.30
image

With 1.29.1 I get
image

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Nov 28, 2018

You're sure your extension is being activated? Can you tell that the server process actually started? Can you find it in Task Manager and verify that its command line args contain the debug attribute?

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

Yup it definitely works and is loaded

Will check the command line in a few

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Nov 28, 2018

@dbaeumer any ideas here?

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

Here's using 1.30 (fails)
image

Here's using 1.29.1 (works)
image

@dbaeumer

This comment has been minimized.

Copy link
Member

dbaeumer commented Nov 28, 2018

@roblourens no, not really since it works with 1.29.1 @eamodio can you connect using chrome ?

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

@dbaeumer Differently than above? #63832 (comment)

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Nov 28, 2018

@dbaeumer It appears that the process simply didn't start in debug mode. I'm not sure how else to debug it, can you try changing the port @eamodio in case something is going on with 6009?

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

@roblourens the command line (screenshots above) shows the process being run exactly the same in both 1.30 and 1.29

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

FYI, I tried this on my laptop (Windows 10 as well) and I am seeing exactly the same behavior -- 1.30 won't attach, but 1.29.1 will

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

I changed the port to 6019 and still see the same

@eamodio

This comment has been minimized.

Copy link
Contributor Author

eamodio commented Nov 28, 2018

@roblourens @dbaeumer
Figured it out! It was caused by VS Live Share! If I disable that, everything works fine. I am running running Live Share in 1.29.1 too, but there must be some incompatibility between Live Share and 1.30.

@weinand

This comment has been minimized.

Copy link
Member

weinand commented Dec 18, 2018

I've investigated this further and found that LiveShare triggers the issue but is not the culprit.

The issue is that with LiveShare the DA is launched from the ExtensionHost instead of being launched from VS Code (which is expected and correct).
By setting debug.extensionHostDebugAdapter to true the problem reproduces without LiveShare being installed.

The question is why the DA's launch location results in different behavior. I've started to debug this and found that the detectProtocolForAttach in node-debug's protocolDetection.ts is part of the problem. If I comment that out, the problem no longer occurs...

@weinand weinand added this to the December/January 2019 milestone Dec 18, 2018

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Dec 18, 2018

So does http://localhost:port/json return something before protocol detection, but not after?

I remember a similar issue with attaching to electron processes but it went away a long time ago with an electron update.

Maybe we can try to do protocol detection by checking that URL first (assuming 'inspector') instead of opening a socket. That seems safer.

@eamodio if this is the case you should be able to work around it by adding "protocol": "inspector"

@weinand

This comment has been minimized.

Copy link
Member

weinand commented Dec 18, 2018

@roblourens When debugging detectProtocolForAttach in node-debug's protocolDetection.ts the problem does not occur... so something seems to be timing related.

BTW, here are repro steps:

@roblourens

This comment has been minimized.

Copy link
Member

roblourens commented Dec 19, 2018

I'm confused, the LSP sample seems to be not working for me. I run it and it activates but I never see the diagnostics or completions that it says I should see...

@weinand

This comment has been minimized.

Copy link
Member

weinand commented Dec 19, 2018

Heureka, I found the issue:

  • the LSP client library (used in the LSP sample) launches the LSP server process only in debug mode if the node.js process (the EH) was started in debug mode. For this the LSP client library checks the process.execArgv for the existence of "--inspect" arguments.
  • the "Attach to server" failed because the LSP server was not started in debug mode because process.execArgv contains no "--inspect" argument (although the EH node.js process was started with an "--inspect" argument). So some code in the EH seems to remove the "--inspect" arguments before the LSP client library has a chance to find those arguments.
  • the only code in VS Code that removes "--inspect" arguments is controlled by an env var "VSCODE_PREVENT_FOREIGN_INSPECT".
  • Since this variable is only set in the EH, this explains why the problem only occurs if the DA runs in the EH: in this case "VSCODE_PREVENT_FOREIGN_INSPECT" is true and inherited to the DA which eventually launches another instance of VS Code as the debug target. And in that VS Code instance the "VSCODE_PREVENT_FOREIGN_INSPECT" variable makes the debug check in the LSP client library fail.

Consequences:

  • "VSCODE_PREVENT_FOREIGN_INSPECT" is another variable that must not leak to programs launched from VS Code. VS Code debugging now removes the env var before launching a DA. @Tyriar the integrated terminal probably needs to do the same.
  • we need robust extension API for determining if in "debug mode. Looking at process.execArgv is not a robust solution (as this issue has shown). See #65390.

What we should learn from this:
Whenever introducing a new env variable, make sure that it does not leak outside of VS Code.

/cc @dbaeumer @alexandrudima @Tyriar @jrieken

@weinand weinand closed this in 42b6e2b Dec 19, 2018

Tyriar added a commit that referenced this issue Dec 27, 2018

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Dec 27, 2018

Fixed for terminal 88f07d4

@sbatten sbatten added the verified label Jan 31, 2019

@vscodebot vscodebot bot locked and limited conversation to collaborators Feb 3, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.