Hang often when debugging an extension and attaching to a language server

[eamodio]

Issue Type: Bug

This seems to be a relatively new occurrence (and I don't see the same issue with 1.27.2), but very often when I'm debugging an extensions and then attaching to its associated language server (most typically with --inspect-brk set), vscode hangs and shows the Window is no responding message. And it seems to never come back. I have to close the window and start over.

EDIT: I've seen it in 1.27.2 as well now :(

VS Code version: Code - Insiders 1.28.0-insider (431ef9d, 2018-10-03T12:44:29.343Z)
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 (20.25GB free)
Process Argv
Screen Reader	no
VM	0%

[eamodio]

A bit more info -- This seems to be only an issue when running with --inspect-brk and I think the culprit, is because when the debugger attaches it immediately breaks (which is expected with --inspect-brk), but since it breaks at the root, it opens my large webpacked js file to break in. And just loading that file is slow, so maybe that triggers something to go wrong.

EDIT: So if I open the js file before attaching and let it "load" -- I dunno what it was doing by it caused my PC to crank for quite a long time before calming down -- it works fine

[isidorn]

@eamodio thanks for providing details. However can you give some reproducable steps so I try to get this on my machine.
So a repository which I can clone and just run a launch config to see this?

[eamodio]

@isidorn I was trying to get better steps (with an oss repo), but the latest insiders is even more broken with regards to debugging extensions -- no call stacks at BP, step just runs rather than steps, etc

[isidorn]

@eamodio can you open a new issue with reproducable steps for broken extension debugging in latest insiders.

I just tried it with a generated extension by a yeomen generator and everything works fine.
Can you reproduce the broken behavior with one of those generated extensions or you only see it for your extension?
Either way a new issue with repro steps would be great. Thanks

[eamodio]

@isidorn opened #60809

[isidorn]

@eamodio thanks I'll investigate

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[roblourens]

Is this still an issue?

[eamodio]

@roblourens yes, it is still reproducible for me -- but the cause is definitely in the opening of a large js file to break in. I've "worked around" the issue by using source-map rather than eval-source-map in my webpack config (for devtool) which not only provides a better debug (stepping) experience (noted here: #60809 (comment)) but also opens the correct source-mapped file which avoids this issue all together.

[roblourens]

Ah ok. Is your webpacked file on disk (editor issue) or just in memory, in which case it's downloaded from the runtime via the debug adapter?

[eamodio]

It is on disk and it is about 10MB.

[roblourens]

That doesn't sound like it should cause an issue. If you just click the file to open it does it open successfully in th eeditor?

[eamodio]

It opens, and then gives a warning about syntax highlighting, but then my CPU just cranks for a LONG time (going on 5+ minutes now) and makes vscode VERY VERY slow. But once it finishes cranking on whatever it is doing, everything returns to normal.

[roblourens]

Ok it sounds like something slightly different happens when it's opened while debugging, but it sounds like a weird edge case and you aren't blocked by this, I'll leave it up to @isidorn to decide whether this should be investigated more.

[isidorn]

@eamodio As far as I understand you get the same experience if you open the file directly or via debug.
My bet would be it is an issue in a textmate grammer when we try to parse the file for tokens. Can you share that file so I try to repro on my machine?

[eamodio]

@isidorn I get a poor experience if I open the file directly, but when the debugger opens it, it will cause vscode to show the Window is not responding message. I have shared the file with @roblourens and he looked into it and your bet is correct about the tokenization. @roblourens was going to open an issue for @rebornix to take a look and they have the file. (I don't want the file shared publicly)

[isidorn]

@eamodio I would first wait for the tokenzitaion to be fixed, once that is done we can see if debugging still shows a problem. Due to that, assigning to backlog
@rebornix please ping once we fix tokenization for that file

[octref]

This happened to me 3 times this week in Insiders. Has never happened before that. My cases:

• I'm developing HTML/CSS extension which uses --inspect but not --inspect-brk

• During debug session VS Code would freeze and I see this message:

  

• There's no way I can get any information about the crash. UI freezes and I can't open DevTool.

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[eamodio]

@isidorn this still happens to me if the debugger opens a large file -- its like the syntax highlighting has to complete before the debugger can jump to set the execution point in the file. Where as if I open the same file in an editor myself, there is no hang. Also this isn't a permanent hang, it just hangs (unresponsive) until the highlighting is complete -- if you wait long enough (and the length of time is dependent on the file size) it will eventually come back

[octref]

@eamodio I used to have that issue when I set debug.inlineValues to true.

[eamodio]

@octref hrm, I do have that set (will try to repro without it), but still imo its an issue that should be fixed as its quite a bad experience when it happens.

[isidorn]

Let's reopen then and I am open for PR's that fix this.
I can also help with code pointers if needed

[eamodio]

It seems to happen even without debug.inlineValues 😢

[roblourens]

Is this a large file that is opened with the correct path in your workspace, or a large file that is loaded from the debugger (and thus would have to be transferred from the DA process)?

If you can repro this consistently, can you get a profile of the renderer process?

[eamodio]

@roblourens

Here is the profile:
Profile-20191122T154431.zip

FYI, this happens 100% of the time

Steps:

1. Open the GitLens repo and turn on break on all exceptions
2. Run yarn watch to build
3. Start debugging and it will break on an exception in lodash and will open extension.js which will hang for 20-30s

[roblourens]

@isidorn any idea what it's disposing?

I tried to repro this a bit with the gitlens repo and couldn't. I am not on windows and also wasn't sure whether I am getting to the right exception, there are a ton of exceptions thrown in the EH.

[eamodio]

@roblourens Once you hit an exception in extension.js you should see the issue.

[eamodio]

@roblourens I just tested on my mac, and it does not hang. It takes it longer to show the exception info, but it is responsive the whole time.

[isidorn]

I do not know why and who is disposing. Do you have more details?
I will try to repro this in a couple of weeks when I get a new machine, my current Win is super slow and unusable.

[isidorn]

Closing as I guess you no longer see this with the new js-debug.
If you do see it please let me know and I can reopen