Leaves behind processes when restarting vscode on linux - Part Deux - Risen From The Dead

[vindicatorr]

Reference: #36 (comment)

Version: 1.36.0-insider
Commit: c089daa858f34631f5f827ff8a0313bf1e2ded6d
Date: 2019-06-07T05:15:26.964Z
Electron: 4.2.3
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.1.15.a-1-hardened

MSBuild project tools: 0.2.55

2019-08-25 12:29:24.536 -05:00 [Verbose/] Logger initialised.
2019-08-25 12:29:25.623 -05:00 [Debug/] Creating language server...
2019-08-25 12:29:26.244 -05:00 [Debug/] Waiting for client to initialise language server...
2019-08-25 12:29:26.730 -05:00 [Debug/] Finding descriptor for "initialize"
2019-08-25 12:29:30.271 -05:00 [Debug/] Starting: Routing Request (0) "initialize"
2019-08-25 12:29:30.395 -05:00 [Debug/] Converting params for Request (0) "initialize" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeParams"
2019-08-25 12:29:30.524 -05:00 [Debug/] Result was "System.Threading.Tasks.Task`1[[OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult, OmniSharp.Extensions.LanguageProtocol, Version=0.7.9.0, Culture=neutral, PublicKeyToken=null]]"
2019-08-25 12:29:30.581 -05:00 [Debug/] Response value was "OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult"
2019-08-25 12:29:30.602 -05:00 [Debug/] Finished: Routing Request (0) "initialize" in 295ms
2019-08-25 12:29:30.917 -05:00 [Debug/] Finding descriptor for "initialized"
2019-08-25 12:29:30.919 -05:00 [Debug/] Finding descriptor for "workspace/didChangeConfiguration"
2019-08-25 12:29:30.965 -05:00 [Debug/] Starting: Routing Notification "initialized"
2019-08-25 12:29:30.983 -05:00 [Debug/] Finished: Routing Notification "initialized" in 15ms
2019-08-25 12:29:31.000 -05:00 [Debug/] Starting: Routing Notification "workspace/didChangeConfiguration"
2019-08-25 12:29:31.002 -05:00 [Debug/] Converting params for Notification "workspace/didChangeConfiguration" to "MSBuildProjectTools.LanguageServer.CustomProtocol.DidChangeConfigurationObjectParams"
2019-08-25 12:29:31.311 -05:00 [Debug/] Finished: Routing Notification "workspace/didChangeConfiguration" in 310ms
2019-08-25 12:29:31.326 -05:00 [Debug/] Language server initialised by client.
2019-08-25 17:31:53.219 -05:00 [Debug/] Finding descriptor for "shutdown"
2019-08-25 17:31:54.480 -05:00 [Debug/] Starting: Routing Request (1) "shutdown"
2019-08-25 17:31:54.489 -05:00 [Debug/] Converting params for Request (1) "shutdown" to "System.Object"

Opened:

$ ps -ef |grep -P ".*(1309|tintoy).*"
username     1309     1  0 12:29 ?        00:02:43 /<pathTo>/VSCode-linux-x64/code-insiders
username     1311  1309  0 12:29 ?        00:00:00 /<pathTo>/VSCode-linux-x64/code-insiders --type=zygote --no-sandbox
...
username     1638  1438  0 12:29 ?        00:00:23 /<pathTo>/.vscode-insiders/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/MSBuildProjectTools.LanguageServer.Host.dll

Closed:

$ ps -ef |grep -P ".*(1309|tintoy).*"
username     1638     1  0 12:29 ?        00:00:23 /usr/bin/dotnet /<pathTo>/.vscode-insiders/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/MSBuildProjectTools.LanguageServer.Host.dll

EDIT0:
Mind you, it doesn't happen all of them time, only when I'm working on stuff.
For example, I just did another quick test by opening vscode to include your extension version here and then closed it and there's only that same instance (1638) listed.

I don't know if it matters if I also had another vscode window open to also work on a c++ project.
I hadn't even worked on any msbuild stuff in this session.
But whatever the difference, ALL vscode instances had been closed and the extension remained.

[tintoy]

Thanks! I'll spend some time this week having a look into it and I'll let you know what I find.

Sorry for the inconvenience :)

[tintoy]

Sorry, still having trouble tracking down down the cause, but I’m working on it :)

[vindicatorr]

No worries, and no rush. I have no dependency on it and think I might only had installed it for json intellisense or something. I really don't remember.

[tintoy]

If you have a moment, would you mind trying again with the latest version (v0.3.2)? It's now running on .NET Core 3.x so I suspect the issue may be resolved (but I could be wrong).

[tillig]

I may have just hit this myself - v0.3.3 on Mac. I was noticing that after a while in a .NET Core 3.1 project with an MSBuild file that after a while of working I'd have a Code Helper process running away with one of my CPU cores. Even after fully quitting out of VS Code, that process would continue on.

Disabling the MSBuild project tools extension seems to alleviate the issue.

It seems like a recent thing; I wasn't having the issue in, say, mid last year... but then I switched over to a bunch of TypeScript and Go projects for a while. I'm just now back in .NET Core and noticed this.

[tintoy]

I still haven’t been able to reproduce this which is driving me a little nuts 😕

Is the dotnet process that represents the language server still hanging around as well? If so would you be able to use dotnet dump to capture a dump of the process so I can try debugging it?

[tillig]

Let me see if I can. I've had it disabled all day and haven't run into it, which is why I'm thinking this is the culprit. I've reenabled it; let me see if I can get more details.

[tillig]

It turns out that, super helpfully, dotnet-dump isn't supported on MacOS.

And, naturally, where I'm seeing it is MacOS.

I did capture three process samples which don't tell me much because I honestly don't know entirely what I'm looking at. I captured two before I quit VS Code and one after I quit and the "Code Helper (Renderer)" process (which is the culprit) was orphaned.

ProcessSamples.zip

Unfortunately, I'm going to plead ignorance on what I should do next. I'm reasonably (a few months?) new to MacOS; normally I'm a Windows person and I'm not afraid of dbgview and SOS and all that, but I don't really know the equivalents on MacOS. I'd be happy to get additional data if you can point me to some links or something to help ramp me up just a touch.

Something to note is that it actually took quite a while before the process went out of control. The past few times it's been nearly immediate when I started working in C#; today it took a couple of hours before the fan kicked into high gear to let me know I should look at my process list. Given that, I'm not honestly sure what kicked it off - what caused it to go nuts.

[tintoy]

Thanks - I’ll have a look when I finish work this afternoon. I don’t know that much about running this on Mac either unfortunately. I’ll see what I can find out.

[tintoy]

Might also be worth posting the output of ps -eo pcpu,user,pid,command | grep Code, if possible.

[tillig]

I've gotten on a project with Terraform and Go code rather than .NET so... I haven't forgotten, I just haven't had the issue since I'm working on some different stuff at the moment. When I get back on a .NET project (soonish?) I'll include more info where possible.

[tintoy]

No problem - I’ve made that particular jump before too :)

[vindicatorr]

Hey, I'm back at it, and your extension isn't the only one (dotnet/vscode-csharp#2851)...
I've got 3 instances of rzls still alive, and 6 instances of yours, all after having closed vscode.

I installed the dotnet-dump tool and dumped one of them (~300MB).
Since it is so large, I don't know if you want me to run some of the commands and provide the output, or if a mini dump would suffice for posting or what.
A sample:

> clrstack                                                                                                                           
OS Thread Id: 0xc376 (0)
        Child SP               IP Call Site
00007FFCA3A10720 00007b7ddb08de32 [GCFrame: 00007ffca3a10720] 
00007FFCA3A10800 00007b7ddb08de32 [HelperMethodFrame_1OBJ: 00007ffca3a10800] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
00007FFCA3A10930 00007B7D608807B4 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)
00007FFCA3A109C0 00007B7D60895060 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2922]
00007FFCA3A10A20 00007B7D60894F04 System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2861]
00007FFCA3A10A70 00007B7D608EB206 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 143]
00007FFCA3A10A90 00007B7D60A64570 System.Runtime.CompilerServices.TaskAwaiter`1[[System.Int32, System.Private.CoreLib]].GetResult() [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 369]
00007FFCA3A10AA0 00007B7D60D61782 MSBuildProjectTools.LanguageServer.Program.Main() [D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer\Program.cs @ 40]
00007FFCA3A10E48 00007b7dda176f7f [GCFrame: 00007ffca3a10e48] 
00007FFCA3A11330 00007b7dda176f7f [GCFrame: 00007ffca3a11330]

[tintoy]

Ooh let me do a little research and get back to you...

[tintoy]

I'm going to try a different approach (dealing with the world as it is, rather than how it ought to be). To this end, the language server is now simply going to watch its parent process for exit; if the parent process exits, the language server will log a message to that effect, attempt to flush its log, and then immediately self-terminate :)