Sentry profiler seems to be leaking memory

[kanadaj]

Package

Sentry.Profiling

.NET Flavor

.NET

.NET Version

10.0.104

OS

Any (not platform specific)

OS Version

Any

Development Environment

Rider 2025.x (Windows)

Other Error Monitoring Solution

No

Other Error Monitoring Solution Name

No response

SDK Version

6.3.0

Self-Hosted Sentry Version

6.1.0

Workload Versions

N/A

UseSentry or SentrySdk.Init call

//...
x.AddProfilingIntegration();
//...

Steps to Reproduce

1. Enable Sentry Profiler Integration via AddProfilerIntegration()
2. Deploy to production for real scale workload
3. Watch memory climb until OOM issues

Expected Result

It shouldn't :P

Actual Result

We seem to have found memory leaks in the Sentry Profiler integration added via AddProfilingIntegration() due to relying on Microsoft.Diagnostics.Tracing.Etlx. The cause seems to be from undisposed instances of TraceLog, with several gigabytes of call stacks accumulating over the period of roughly an hour for us, eventually causing process memory starvation and crashes.

[linear-code]

NET-650

[jamescrosswell]

Hi @kanadaj ,

Without a minimal reproducible example, it's very difficult to say what might be happening.

Deploy to production for real scale workload

Specifically this... would be very hard to guess at. What about your production scale workloads is necessary for the problem to manifest? We'd just be stabbing in the dark trying to recreate this here.

[github-actions]

👋 Thanks for the report! We've added the Needs Reproduction label because we need a minimal reproduction to investigate further.

Please provide a link to a public GitHub repository that reproduces the issue with as little code as possible. Our repro guide has tips on how to create one.

Some quick hints:

• Start from a fresh dotnet new console (or similar) project
• Add only the Sentry NuGet package(s) relevant to the bug
• Include the exact SDK version number and your SentrySdk.Init / UseSentry call (with the DSN blanked out)

Alternatively, if the issue only manifests in your own codebase, you could try gradually removing code until you have a minimal repro.

[tvardero]

Can confirm that, we had tried profiling with asp.net core back in January, in production it was eating ram. I'll try find some memory dumps before oom, will attach a bit later.