fix: bound profiler memory growth by trimming interned call stacks

[jamescrosswell]

Stacked on #5502 to keep the mechanical changes for the submodule bump independent of the fix itself. This PR targets deps/update-perfview and is just the fix.

Fixes #5469

What was leaking

TraceCallStacks.InternCallStackIndex interns every distinct call stack it observes and never
releases any of them. That is correct for a trace file, which is finite, but the profiler's
EventPipe session runs for the life of the process — so the tables grow forever. Two properties made
it worse than it sounds: growth tracks the diversity of stack shapes rather than sample volume,
and it happens whether or not a profile is running, which is why lowering ProfilesSampleRate
never helped and only setting it to 0 did.

The fix

TraceLog.TrimLiveSessionState() (microsoft/perfview#2452, contributed for this) discards those tables. This wires it up from an always-on ThreadSample handler on the factory.

A trim reissues CallStackIndex from zero, and SampleProfileBuilder caches against it, so a stale entry would resolve a sample to an unrelated stack — wrong frames, no exception.

So the cache must be invalidated. SampleProfilerSession carries a generation that increments on every trim; SampleProfileBuilder records what it saw and drops _stackIndexes when the generation increments. Affected stacks get walked again, at worst appearing twice in Profile.Stacks, which samples reference by the builder's own ids. Potentially we spend a bit more CPU then - but we avoid the memory leak.

Both run on the dispatch thread, so ordering can't bite: trim-then-AddSample sees the bump and
clears, AddSample-then-trim resolved against tables that were valid at that instant and sees the
bump next time.

The builder's other caches need no handling: _frameIndexesByCodeAddressIndex and
_frameIndexesByMethodIndex key off tables a trim doesn't touch, and _threadIndexes keys off
TraceLog.Threads, which is a different table from the per-thread roots inside TraceCallStacks.

Trim Frequency

MaxCallStackCount is 100,000 (~10 MB of tables) - roughly every 7 minutes in the reporting customer's scenarion, and a trim measured at ~0.012 MiB of unreturned RSS. It is an internal static rather than a SentryOption - we could expose this if there was a compelling reason but I think best to leave internal initially.

Why not just restart the session

That was the obvious alternative and it was measured and rejected: it bounds managed memory but costs
3.1–3.3 MiB of RSS per recycle that is never returned, making RSS grow roughly 3x faster than the
leak. Trimming in place costs ~0.012 MiB, because no new EventPipe session is created.

Effect

Same workload, 600 s, real time session on .NET 9 in a Linux container:

	without trim	with trim
interned call stacks at 600 s	1,231,862, still climbing	bounded, cycling 919 – 7,121
managed heap	3.4 → 119.2 MiB	3.5 → ~7 MiB, flat
RSS	65.2 → 200.7 MiB	65.6 → 81.4 MiB
samples processed	307,418	340,987

Throughput went slightly up, since the baseline spends real time growing and collecting those
tables. That workload is deliberately far more stack-diverse than a real service so the effect is
measurable in minutes — the shape matches the field report, the rate is exaggerated.

Test

Profiler_WhenNoProfileRunning_TrimsInternedCallStacks covers the idle path — no profile is ever
started, so the trim has to come from ordinary samples.

Profiler_WhileProfileRunning_StillTrimsInternedCallStacks covers the starvation case: it holds a
profile open for the whole test, asserts trimming still happens, then collects and validates the
profile to show a mid-profile trim doesn't corrupt its output. Both were mutation-tested — restoring
the old _inProgress guard makes the second fail with "No trim occurred while a profile was running".

Sentry.Profiling.Tests on net10.0: 19 passed, 0 failed, 3 skipped. net8.0/net9.0 hosts can't be
launched locally (no arm64 runtimes for those on this machine), so CI covers those.

Changelog Entry

fix: Memory leak in Sentry.Profiling due to EventLog interning tables growing indefinitely

[codecov]

Codecov Report

❌ Patch coverage is 7.69231% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.67%. Comparing base (4e0e0de) to head (908f26f).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
...ry.Profiling/SamplingTransactionProfilerFactory.cs	14.28%	12 Missing ⚠️
src/Sentry.Profiling/SampleProfileBuilder.cs	0.00%	6 Missing and 1 partial ⚠️
src/Sentry.Profiling/SampleProfilerSession.cs	0.00%	4 Missing ⚠️
...rc/Sentry.Profiling/SamplingTransactionProfiler.cs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5503      +/-   ##
==========================================
- Coverage   74.74%   74.67%   -0.07%     
==========================================
  Files         513      515       +2     
  Lines       18829    18909      +80     
  Branches     3682     3691       +9     
==========================================
+ Hits        14074    14121      +47     
- Misses       3875     3904      +29     
- Partials      880      884       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 21be80c. Configure here.}

[vaind]

Approach LGTM, some minor things below.

[vaind]

🤖 says

SamplingTransactionProfilerTests carries [CollectionDefinition(..., DisableParallelization = true)] on itself, which defines a collection but doesn't join it — xUnit needs [Collection(name)] on the class. Tests inside one class serialize regardless, so the two new tests can't collide with each other. But ProfilingSentryOptionsExtensionsTests runs in a separate collection, and HubDispose_* starts real EventPipe sessions — those will run with a budget of 100 during the 3-second windows. Harmless today (they only assert IsDisposed), but it's a trap for the next test that asserts on profile content. An instance field on the factory instead of a static removes the global mutation and both try/finally blocks.

[jamescrosswell]

Good catch... fixed (partially) in 908f26f

Also created:

• Profiling tests never actually opt out of parallel execution #5524

That might explain why we've had issues with flaky profiling tests (locally and in CI).