Omnisharp freezes during extension initialization with excessive CPU usage

[rjgotten]

Environment data

VS Code version: 1.42.1
C# Extension version: 1.21.13

Steps to reproduce

• Startup VS Code
• Wait for intellisense to populate, which doesn't happen.
• Try to restart Omnisharp via the command pallete; it doesn't respond.

Look at the extension host log, which will list a sequence of:

[exthost] [error] [ms-dotnettools.csharp] provider FAILED
[exthost] [error] Problem invoking 'GetCodeActions' on OmniSharp server: Error: Pending request cancelled: /v2/getcodeactions

Expected behavior

For the extension to be well behaved.

Actual behavior

The extension is broken and doesn't initialize correctly.
Occasionally VSCode will complain about excessive CPU usage.

Once frozen have to close VS Code down (as the command pallete to restart Omnisharp doesn't work) and start it back up, then let Omnisharp sit there spinning rims for ~5m before whatever is blocking it gives up and the extension hopefully initializes without hanging indefinitely again.

[rjgotten]

NOTE

Reverting to 1.21.12 fixes this issue.

[rjgotten]

Found the following in the event viewer logs, which may or may not have something to do with the issue? (Frankly the 1.21.13 version makes VS Code so unstable that I cannot really judge anymore.)

Regardless of whether this ties into the freezing problem or not, there also appears to be a compatibility problem with the Razor language service now.

Application: rzls.exe
CoreCLR Version: 5.0.20.11909
.NET Core Version: 
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AggregateException: One or more errors occurred. (The type initializer for 'Newtonsoft.Json.Serialization.DefaultSerializationBinder' threw an exception.)
 ---> System.TypeInitializationException: The type initializer for 'Newtonsoft.Json.Serialization.DefaultSerializationBinder' threw an exception.
 ---> System.IO.FileNotFoundException: 
File name: 'System.Collections.Concurrent, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Newtonsoft.Json.Utilities.ThreadSafeStore`2..ctor(Func`2 creator)
   at Newtonsoft.Json.Serialization.DefaultSerializationBinder..ctor()
   at Newtonsoft.Json.Serialization.DefaultSerializationBinder..cctor()
   --- End of inner exception stack trace ---
   at Newtonsoft.Json.JsonSerializer..ctor()
   at Newtonsoft.Json.JsonSerializer.Create()
   at Newtonsoft.Json.JsonSerializer.Create(JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonSerializer.CreateDefault()
   at OmniSharp.Extensions.JsonRpc.Serialization.SerializerBase.CreateSerializer()
   at OmniSharp.Extensions.LanguageServer.Protocol.Serialization.Serializer.CreateSerializer()
   at Microsoft.AspNetCore.Razor.LanguageServer.Program.MainAsync(String[] args)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait()
   at Microsoft.AspNetCore.Razor.LanguageServer.Program.Main(String[] args)

[NTaylorMullen]

@rjgotten that looks like a result of failed extension initialization but not a cause. If you:

• Uninstall C# extension
• Close VSCode
• Re-open VSCode
• Re-install C# extension

Doing these steps will force O# to re-fetch the Razor language server which should then have the appropriate bits included.

[rjgotten]

@NTaylorMullen
So it's a symptom, then? Good to know.

---

I've reverted back to 1.21.12 in the meantime via VSIX install so it also has the old publisher ID, avoiding the issues related to the publisher ID switch as well.

Taken as a whole 1.21.13 is just broken. Imho it should be pulled and maybe 1.21.12 should just be republished under the new publisher ID with no further changes.

[JoeRobich]

Please try the v1.21.15 prerelease and let us know if it resolves your performance issue.

[kieranbenton]

It does not - I have had to revert to .12 as well - this should be a high priority fix, makes using vscode with C# almost impossible for an extended period of time at the moment!

[JoeRobich]

@kieranbenton Can you give us more details about you project? Others have reported this same issue with asp.net projects containing large 'node_modules' folder or Unity projects with a large 'PackageCache' folder. What type of project are you building and do you have any folders with many nested subfolders in your project?

[kieranbenton]

Sure (sadly not OSS so can't just dump you some stats directly) - I'd classify it as a relatively complex solution folder with a handful of top level folders (k8s, src, tests).

Src is the biggy - 14 csharp projects in folders in there. 5 are applications. Rest are libraries.

Apps range from a 'mostly react/nextjs SPA with lightweight ASP MVC backend' app, to a heavy ASP.NET Core MVC app, to command line apps. So yes, node_modules is present - I wouldn't say its unusual usage though?

cloc . --exclude-dir=node_modules,bin,obj,packages,dist,lib,.next

gives... (I can give you without the excludes if you like but this is usually what I use to give me an idea of size)...

    5835 text files.
    5798 unique files.
     173 files ignored.

github.com/AlDanial/cloc v 1.74  T=113.10 s (50.3 files/s, 2122.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C#                            2401          26169          18888         120708
TypeScript                     492           4069           2352          19940
SQL                            233            939           1880           9849
CSS                             33           1922             97           8846
Razor                          223           1297            320           8746
JSON                          2166              2              0           8314
Sass                            45            265             58           1624
YAML                            20             36             27            782
MSBuild script                  19             85             21            608
Smalltalk                        5             98            176            411
JavaScript                      10             67            155            381
Bourne Shell                     9             85            103            260
Dockerfile                       7             60             55            195
Markdown                        15             47              0            111
HTML                             2              0              0             25
PowerShell                       3              4              6              6
INI                              1              1              0              4
Qt Linguist                      3              0              0              3
-------------------------------------------------------------------------------
SUM:                          5687          35146          24138         180813
-------------------------------------------------------------------------------

Happy to provide more info if you can let me know what you want to know - or try builds out for you if you like.

Cheers!

[JoeRobich]

@kieranbenton Is '/node_modules' in either your files.exclude or search.exclude vs code configuration?

[kieranbenton]

Yup.

	"files.exclude": {
		"**/.git": true,
		"**/bin": true,
		"**/obj": true,
		"**/node_modules": true,
		"**/wwwroot/skins/*.css": true,
		"**/wwwroot/skins/*.map": true
	},

[JoeRobich]

@kieranbenton If what you are experiencing is the same as other users, the problematic code is searching for files under the 14 C# project folders. It takes advantage of the files.exclude and search.exclude settings to limit this search even further. So if you are still seeing similar performance issues with v1.21.15 then we need to find a more efficient search pattern.

@NTaylorMullen I know you were thinking about limiting the search to */Properties/launchsettings.json, is that a valid optimization?

[kieranbenton]

Is there anything I can do to confirm that we are experiencing the same issue? Any logs to look for?

[JoeRobich]

@kieranbenton Has VS Code popped up to recommend that you log an issue and provided you a .cpuprofile to share? See https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

[NTaylorMullen]

@NTaylorMullen I know you were thinking about limiting the search to */Properties/launchsettings.json, is that a valid optimization?

I aborted that conversation to figure out. I can re-ignite it to find out if it's valid.

[kieranbenton]

@JoeRobich nope - not had any of that, it just hangs

[rjgotten]

@JoeRobich
Please try the v1.21.15 prerelease and let us know if it resolves your performance issue.

Seems to have done the trick for me.
Need to test further, but it looks promising so far.

[JoeRobich]

@kieranbenton Before publishing 1.21.15 we made a final change to remove any file searching at all. Can you please try the public release and let me know how it performs?

[JoeRobich]

@rjgotten Thanks for the report. Closing this now that 1.21.15 has been published.

[kieranbenton]

@JoeRobich just upgraded again to .15 and it does indeed look as if this has been resolved. Cheers!