Never free a call-trace table a put() may still hold after a drain timeout - #840

What does this PR do?:

Documents how CallTraceStorage reclaims tables relative to put(), and makes it never free a table that a put() may still be writing after a timed-out drain. No memory is leaked in normal operation: the leak path below is only taken after a drain timeout, which no production caller can hit today.

• Reclamation and put(). processTraces() and the destructor tolerate concurrent put(). They only reclaim a table after swapping it out of _active_storage, which put() re-checks after taking its guard, and after draining its guards. clear() resets the active table in place, so it requires put() to be excluded. Today lockAll() excludes put() from all of them anyway. This is now stated on the class, the methods and in CallTraceStorage.md. The old comment said processTraces() "is safe to call concurrently with put() operations" without qualification.
• RefCountGuard::waitForRefCountToClear() now returns whether it drained. Debug builds still abort on a timeout. Gtest builds (UNIT_TEST) skip the abort so they can exercise the release behavior.
• On a timeout:
  • clearTableOnly() leaks the detached chunks: it returns an empty ChunkList.
  • The destructor skips the delete.
  • Before this change, release builds freed the memory anyway.
• Corrects the PROF-14889 explanation in clearTableOnly() and in the header of ProcessCallTracesRaceTest. Both described collect() racing an in-flight put(), which lockAll() rules out. It also adds the missing copyright header to that test file.

Motivation:

PROF-16136 asked for an audit of the other drain callers. CallTraceStorage uses the same "drain, then free regardless" pattern as the dictionary, but there it is latent, not reachable:

• Every put() runs under one of the Profiler stripe locks (profiler.cpp callers at 641/726/855; the earlier unlock()s are early returns).
• Every caller of processTraces() (writeStackTraces() ← finishChunk() ← FlightRecorder::stop()/dump()) and of clear() holds lockAll().
• lockAll() waits for in-flight put()s without a time limit, so the drains find no guard and cannot time out.
• The destructor never runs, because Profiler::_instance is never deleted.

This was already true when #585 (PROF-14889) landed. So the 500 ms timeouts it observed must have come from the old global wait counting guards on other resources, i.e. StringDictionary lookups, which lockAll() does not exclude. #839 removes that global wait.

Additional Notes:

• No behavior change on any path production can reach. lockAll() is held for the dump because of the per-stripe JFR buffers; it covers CallTraceStorage incidentally. If that ever changes, the rotation path stays memory-safe with this PR (a stalled put() costs a leaked table in release, an abort in debug), but clear() would need its own gate.
• On a broken contract processTraces() waits and logs twice: once after the swap, and again inside original_active->clear(). Collection from the old active table still proceeds, as before.
• StringDictionary::rotate() also calls waitForRefCountToClear() and keeps aborting in debug builds on a timeout. In release, the clearStandby() drain added in Never reclaim dictionary storage after a timed-out drain #839 covers it.

How to test the change?:

New gtest CallTraceHashTableDrainTest.ClearWithGuardHeldLeaksChunks. It holds a RefCountGuard on a table while calling clear(), then reads a trace from the old chunk.

• Before this change: exits 134, from the old debug abort.
• With the abort skipped but no leak: ASan reports SEGV reading the munmapped chunk at held->trace_id.
• With this change: passes in debug, ASan and TSan.

Also run:

• gtestDebug (full), and test_callTraceStorage under ASan and TSan.
• compileFuzzer.
• testDebug: 225 tests, 0 failures, 19 skipped (includes ProcessCallTracesRaceTest).

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a security review (run the dd:platform-security-review
  skill, or file a request via the PSEC review form).
  bewaire also runs automatically on every PR.
• This PR doesn't touch any of that.
• JIRA: PROF-16136

🤖 Generated with Claude Code