Type Provider leaking memory in FSAC

[TheAngryByrd]

Please provide a succinct description of the issue.

👋 I've been experiencing type providers leaking memory in the Adaptive LSP server in FSAC. It seems to happen when type checking across projects. On a file save, FSAC will scan for all dependent files and projects and type check them as well. When type providers are involved, it seems to recreate the type providers over and over and not releasing the older ones.

I can't get this to reproduce in Rider or VS so I'm not sure if it's related to the specific FCS version or the way FSAC is using FCS.

---

I think #14754 might benefit here but I still get the feeling something about lifetime management isn't working correctly. I did a very naive implementation of caching calls to CreateTypeProvider and it doesn't seem to create more instances.

Also somewhat related issues:

• Type providers get created hundreds of times causing large LOH allocations and UI delays inside VS #5929

Provide the steps required to reproduce the problem:

https://github.com/TheAngryByrd/css-type-provider-memory-leak

Expected behavior

No leaks.

Actual behavior

Here is a screenshot of dotmemory showing ResolveEventHandler's holding onto old information.

Known workarounds

Provide a description of any known workarounds.

• Use VS or Rider
• Don't use type providers

Provide any related information (optional):

 dotnet --info
.NET SDK:
 Version:   7.0.202
 Commit:    6c74320bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.202\

Host:
  Version:      7.0.4
  Architecture: x64
  Commit:       0a396acafe

.NET SDKs installed:
  5.0.404 [C:\Program Files\dotnet\sdk]
  6.0.101 [C:\Program Files\dotnet\sdk]
  6.0.203 [C:\Program Files\dotnet\sdk]
  6.0.407 [C:\Program Files\dotnet\sdk]
  7.0.100-rc.2.22477.23 [C:\Program Files\dotnet\sdk]
  7.0.100 [C:\Program Files\dotnet\sdk]
  7.0.202 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0-rc.2.22472.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.0-rc.2.22472.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[T-Gro]

I think it is already wrong higher up - the fact that you have 2K (2.000) ResolveEventHandler instances is the suspicious thing.

The event handler should be detached as soon as DependencyResolver is .Disposed()'d.
The event handler is attached to the assembly resolve event at creation, and only removed on Disposal of dependency resolver.

Can't this be the reason?

[TheAngryByrd]

I took at look at anything we're using that uses AssemblyLoadContext. Something things I've tried but didn't seem to be the issue:

• Ionide/proj-info seemed like it might be the culprit but adding caching/logging didn't prove to be the cause.
• I also stopped calling LoadAnalyzers in the analyzers SDK but didn't change anything either.

Maybe there's something in another dependency I'm not seeing. I don't know if there's any easy way to trace why so many ResolveHandlerEvents get created.

[T-Gro]

The compiler service keeps one dependency resolver around, this should not lead to thousands of handlers.
Are by any chance multiple compiler service instances being created, or background compilers?

[TheAngryByrd]

This seems like a problem in FSharp.Compiler.Service 43.7.200 After building FSAC against in the main branch I don't see the handlers growing out of control.

There are still a lot of ProvidedTypesContext objects but maybe this is an issue with the TPSDK/the type provider an an old TPSDK.

[T-Gro]

That is curious, I will check what has changed - I haven't seen any issue trying to explicitely address this.

[TheAngryByrd]

Haven't seen this in a long time gonna close it.