Debug adapter process has terminated not at all unexpectedly

[oliversalzburg]

Issue Type: Bug

The Node debug adapter crashes at least a dozen times every single day for one of my projects.

In a previous ticket I was told that this is not supposed to happen, which is also the reason why no more information regarding the cause is made available to the user. I still think that's a mistake, but I would happily accept a solution where the adapter is simply not crashing anymore.

I'm currently using Node 8.11.1

VS Code version: Code 1.24.1 (24f6262, 2018-06-13T17:51:32.889Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz (12 x 3672)
GPU Status	2d_canvas: enabled 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: disabled_software video_decode: enabled video_encode: enabled vpx_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	63.91GB (33.61GB free)
Process Argv	C:\Program Files\Microsoft VS Code\Code.exe .
Screen Reader	no
VM	0%

Extensions (8)

Extension	Author (truncated)	Version
bracket-pair-colorizer	Coe	1.0.58
vscode-eslint	dba	1.4.12
EditorConfig	Edi	0.12.4
vscode-esformatter	how	1.6.0
output-colorizer	IBM	0.1.2
vscode-lebab	mrm	2.5.0
vscode-puglint	mrm	2.3.0
debugger-for-chrome	msj	4.7.0

(1 theme extensions excluded)

[vscodebot]

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

• It is not possible to see any error output from crashed debug adapter extension (#40198)

[weinand]

@oliversalzburg please provide reproducible steps.

[oliversalzburg]

If you tell me how to get the information on what caused the crash, I'll tell you how to reproduce it.

[weinand]

Without steps for how to reproduce it, we won't be able to help you.

[oliversalzburg]

That's understandable. I was hoping for some guidance on how to possibly find the source of this seemingly random occurrence. Beyond the notification and the process silently exiting, I have nothing to go on.

[roblourens]

If the debug adapter has more details, it typically writes them to the debug console. If you set "trace": true in your launch config, the adapter will write a log file that may have more details. It's worth a shot.

Also, we just released 1.25, please see if it's any better in the new release.

[oliversalzburg]

Yeah, there is nothing in the debug console except the last lines of output from my own code, which gives no clues.

I'll try running with trace enabled, but this issue usually only happens after longer periods of time (30m and longer). From what I remember, the amount of data produced from tracing is excessive and I anticipate problems with this approach, but we'll see.

And, yes, I made sure this time it's a not a conditional breakpoint. In case anyone was wondering.

[oliversalzburg]

So far, I can only say that it's not fixed with 1.25. I wasn't working in the project that routinely has this issue for a couple of days and now it started happening right away again.

[roblourens]

Are you able to get a trace?

[oliversalzburg]

Are you able to get a trace?

I'll look into that next week. I was briefly working in a different area and didn't get much input on this particular issue.

[oliversalzburg]

Alright, I just had a run with trace enabled and produced a nice 1.2 GB log file. It ends with:

To client: {"seq":0,"type":"event","event":"loadedSource","body":{"reason":"new","source":{"name":"VM73598","path":"<eval>/VM73598","sourceReference":74578,"origin":"read-only content from Node.js"}}}
To client: {"seq":0,"type":"event","event":"loadedSource","body":{"reason":"new","source":{"name":"VM73599","path":"<eval>/VM73599","sourceReference":74579,"origin":"read-only content from Node.js"}}}
To client: {"seq":0,"type":"event","event":"loadedSource","body":{"reason":"new","source":{"name":"VM73600","path":"<eval>/VM73600","sourceReference":74580,"origin":"read-only content from Node.js"}}}

The process that hosts the debug adapter was using around 2.4 GB memory when it crashed. This was increasing steadily over the entire run.

The log compresses nicely to just under 3 MB. Should I send it over?

[roblourens]

I wonder if it just ran out of memory. I would like to see the log, thanks.

[oliversalzburg]

I wonder if it just ran out of memory.

The behavior feels like it. Especially the aspect that this only happens after longer periods and I watched the memory usage climb steadily as I was collecting the log. Although I was not sure if that is linked to the collection of the log.

The last time this happened (#49829) was with the conditional breakpoint. That should not be the case this time.

[roblourens]

From your log, there are just a ton of loaded scripts - for example, bluebird is doing a lot of evals. The debug adapter has to save some details of every loaded script even though most of them are not useful.

I found a couple easy ways to reduce the amount of data we have to keep around. Please try it out in Insiders or 1.26 next week.

[oliversalzburg]

@roblourens Cool. I'll check out 1.26 and report back.

[oliversalzburg]

So far, no more crashes in 1.26. Will continue to observe. 👍

[roblourens]

Great! 🎉