roslyn: Long-running VBCSCompiler.dll process runs at 100% CPU after parent process dies

Version Used: Using dotnet SDK 2.2.0-preview1-007866 on macOS 10.13.2

Steps to Reproduce: TBH not sure 100% how to get into bad state. I don’t know what is launching VBCSCompiler.dll. The parent process is gone…which is the issue.

But, it has been happening fairly often over the last few days while working on the https://github.com/dotnet/cli repo using VS Code - Insiders + C# extension 1.13.1.

If someone can point me to how to capture more information about how this long-running compiler server starts, I can provide a better repro.

Expected Behavior: No long running compiler process after I shutdown tools and build scripts.

Actual Behavior:

VS Code is closed, and I’ve killed the the build.sh script, yet I have two VBCSCompiler processes running. ps reports the processes have been open for ~ 18 hours.

The process was launched with these arguments:

/Users/namc/.dotnet/dotnet /Users/namc/.dotnet/sdk/2.2.0-preview1-007866/Roslyn/bincore/VBCSCompiler.dll -pipename:namc.False.bZ9mpL2HFmG8IVwxPkEmz6_N4OMYW1cLZOeZGRjGfv0

Process sample: processample.txt

[EDIT]

See below for a workaround: https://github.com/dotnet/roslyn/issues/24137#issuecomment-388494024

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 13
Comments: 25 (9 by maintainers)

Commits related to this issue

Limit compiler server pipe name length (#24265) On MacOS pipes are implemented using Unix domain sockets. Unix domain sockets must have a valid file path for their endpoint. The best place is in th... — committed to dotnet/roslyn by agocke 6 years ago
Use new pipe API for compiler server on Unix The default behavior for the NamedPipeServerStream API is to take a pipe name and then construct a named pipe in the background using that name. In Window... — committed to agocke/roslyn by agocke 5 years ago

Most upvoted comments

I was able to workaround this issue by creating the file ~/Library/LaunchAgents/UseSharedCompilation.plist with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>UseSharedCompilation</string>
  <key>ProgramArguments</key>
  <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv UseSharedCompilation false</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Then logout and login. This should disable the shared compiler server for all apps, including Terminal, Visual Studio Code, and Visual Studio for Mac.

The workaround should be compatible with OS X Yosemite (10.10) or later.

+11

mikeharder on May 11, 2018

I also have the same issue, even after manually killing all on the next build they all come back

I’ve also set DOTNET_RUNNING_IN_CONTAINER=true TMPDIR=/tmp

We are using teamcity and have also updated to the latest dotnet-cli runner

danpowell88 on Oct 23, 2018

I am still facing this issue. Running on MacOS 10.14.4 on VSCode

dhaval24 on May 5, 2019

I’ve started to notice this on JetBrains Rider but I can also reproduce with dotnet run.

CPU usage spikes up to over 600%~700%(!!) during build, and the process behind it is VBCSCompiler.dll as ps aux | grep dotnet shows:

salman           30652 688.2  2.1 27492068 355704 s002  R+    1:54AM   0:12.86 /usr/local/share/dotnet/dotnet exec /usr/local/share/dotnet/sdk/5.0.400/Roslyn/bincore/VBCSCompiler.dll -pipename:8ROgtOzwNr8pY_Moy43ni7FvbMZBvkoQpysLYCewL3w

Running on macOS Big Sur 11.5.1.

dotnet info:

[I] salman@Salmans-MBP ~/Desktop (master) [1]> dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.400
 Commit:    d61950f9bf

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.0
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/5.0.400/

Host (useful for support):
  Version: 5.0.9
  Commit:  208e377a53

.NET SDKs installed:
  3.1.105 [/usr/local/share/dotnet/sdk]
  3.1.301 [/usr/local/share/dotnet/sdk]
  3.1.405 [/usr/local/share/dotnet/sdk]
  3.1.406 [/usr/local/share/dotnet/sdk]
  3.1.407 [/usr/local/share/dotnet/sdk]
  3.1.408 [/usr/local/share/dotnet/sdk]
  3.1.411 [/usr/local/share/dotnet/sdk]
  3.1.412 [/usr/local/share/dotnet/sdk]
  5.0.101 [/usr/local/share/dotnet/sdk]
  5.0.102 [/usr/local/share/dotnet/sdk]
  5.0.103 [/usr/local/share/dotnet/sdk]
  5.0.201 [/usr/local/share/dotnet/sdk]
  5.0.202 [/usr/local/share/dotnet/sdk]
  5.0.302 [/usr/local/share/dotnet/sdk]
  5.0.400 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.19 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.23 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

I would appreciate getting a workaround or a solution to this as it really annoys me when casually building projects.

I’ve tried disabling VBCSCompiler via /p:UseSharedCompilation=false, but it has absolutely no effect and VBCSCompiler still shows up.

frenzibyte on Aug 31, 2021

Similar issues on a long running Teamcity build agent

.NET Core SDK (reflecting any global.json):
 Version:   2.1.402
 Commit:    3599f217f4

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.402/

Host (useful for support):
  Version: 2.1.4
  Commit:  85255dde3e

.NET Core SDKs installed:
  2.0.0 [/usr/share/dotnet/sdk]
  2.1.3 [/usr/share/dotnet/sdk]
  2.1.105 [/usr/share/dotnet/sdk]
  2.1.402 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

ChrisMcKee on Sep 20, 2018

Another workaround: if you set the TMPDIR environment variable to /tmp, that will probably fix the problem and let you still use the compiler server.

agocke on Jul 27, 2018