Open vindicatorr opened 4 years ago
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 :)
Sorry, still having trouble tracking down down the cause, but I’m working on it :)
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.
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).
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.
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?
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.
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.
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.
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.
Might also be worth posting the output of ps -eo pcpu,user,pid,command | grep Code
, if possible.
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.
No problem - I’ve made that particular jump before too :)
Hey, I'm back at it, and your extension isn't the only one (https://github.com/OmniSharp/omnisharp-vscode/issues/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]
Ooh let me do a little research and get back to you...
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 :)
Reference: https://github.com/tintoy/msbuild-project-tools-vscode/issues/36#issuecomment-520186372
MSBuild project tools: 0.2.55
Opened:
Closed:
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.