Memory Leak when using Sentry Profiling

[Skyppid]

Package

Sentry

.NET Flavor

.NET

.NET Version

8.0.6

OS

Windows

SDK Version

4.7.0

Self-Hosted Sentry Version

No response

Steps to Reproduce

Enable profiling like this in the UseSentry configuration delegate:

o.AddIntegration(new ProfilingIntegration());
if (builder.Environment.IsProduction())
{
    o.ProfilesSampleRate = 0.05;
    o.TracesSampleRate = 0.2;
}
else
{
    o.ProfilesSampleRate = 0.2;
    o.TracesSampleRate = 0.5;
}

Run app and wait. It constantly leaks memory even if no requests occur at all.

Expected Result

No memory leak

Actual Result

As you see the app is completely idle. No requests happening. App just started and did nothing yet. Constantly increases memory.
On our staging cluster the app scaled to 10 pods in only a few minutes due to the memory leak.

Disabling the profiling fixes the problem.

Further data:

As you can see the memory constantly grows. The snapshots show the difference between when the app is fully started and ~2 minutes of idle.

EDIT: This screenshot is after 50m of idle runtime.

[bitsandfoxes]

Hey @Skyppid, thanks for reaching out. Do you have a repro-sample for us to easily reproduce this?

[Skyppid]

SentryLeak.zip

It's literally just the ASP.Net API template with Sentry added. Add some DSN if even necessary and run it. It'll leak constantly.
Not so unlikely that this is caused by .NET itself - we have several memory leak issues with .NET 8 as of now. But I guess you should be aware and best use your standing to get this solved with the .NET team if it's not your fault.

EDIT: Seems to be only related to Profiling - Sampling seems to working without leaks.

[klemmchr]

I can confirm huge memory problems with profiling in .NET in general too. We've activated it for our testing system and memory went through the roof while at the same time responses were incredibly slow.

[bitsandfoxes]

It looks like we've got duplicate issues going on regarding memory consumption/leak and CPU requirements. I'm closing this in favor of #3199
Thanks for the detailed reports and the repro @Skyppid
Based on #3199 (comment) it looks like we're making some progress towards resolving this.
Thanks for your continued patience and your efforts in reporting this!