feat: Include RUM context in crash reports

[awforsythe]

refs: RUM-14026

This PR builds upon #181 to make the CrashReporting feature respond to changes in CoreContext, allowing the crash handler implementation to be notified when RumFeatureContext changes so that it can persist RUM UUIDs to be included in crash reports.

• CrashReporting implements MakeMessageHandler, returning a function that handles ContextChangedMessage
  • Whenever context changes, this handler function will run on the messaging thread
  • This function calls a new method, ICrashHandler::SetRumContext, if and only if RUM UUIDs have changed
• CrashpadCrashHandler implements SetRumContext by formatting UUIDs as strings and storing them in crashpad::StringAnnotation values
  • When a crash occurs, the crashpad_handler process reads these values from the crashing process's memory and includes them in the multipart/form-data upload
• InProcessCrashHandler implements SetRumContext by flushing UUIDs to disk in a binary format
  • The in-process handler now writes two files to disk:
    • crash_<timestamp>_<pid>: kept open for the lifetime of the SDK; written to from async-signal-safe path in the event of a crash
      • This is the crash report file: it contains the essential details of the crash
    • crash_<timestamp>_<pid>.ctx: repopulated in full and closed/flushed any time crash context changes
      • This is the crash context file: it describes the state of the application just before the crash occurred
      • We write to .ctx.tmp and then rename to .ctx to ensure atomic writes
  • Flushing to a separate file is necessary because context changes are async, and it's impossible to synchronize those updates with reads (in the crashing thread) using in-process means: i.e. we can't acquire locks in the async-signal-safe crash handler path
  • When SetRumContext is called, indicating that UUIDs have meaningfully changed, those binary values are reserialized to the context file
• NoopCrashHandler implements SetRumContext by doing nothing :)

Additionally, the temporary Python tooling in process-crash-report is updated to read the context file and parse RUM IDs, allowing us to validate that our crash reports have accurate context.

[datadog-datadog-prod-us1-2]

✅ Code Quality    ✅ Code Vulnerabilities    ✅ Library Vulnerabilities    ✅ Secrets

🎉 All green!

🛠️ No new code quality issues
🛡️ No new code vulnerabilities
📚 No new vulnerable libraries detected
🔑 No new secrets detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 9dd9597 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[awforsythe]

/gitlab resync-job-status

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-03-13 11:55:33 UTC ℹ️ Start processing command /gitlab resync-job-status

---

2026-03-13 11:56:02 UTC ℹ️ Devflow: /gitlab resync-job-status

30 jobs status updated and 12 skipped for a total of 42 jobs

[awforsythe]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 473bd16d1e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

NUL-terminate UUID buffer before setting Crashpad annotations

UUID::ToBytes serializes exactly 36 characters without a terminator, but this buffer is passed directly to StringAnnotation::Set as a C-string. When buf[36] is non-zero, annotation writes can include trailing stack garbage (and potentially read past intended bounds), so crash uploads may contain corrupted RUM IDs. Ensure the buffer is explicitly terminated (or use a length-aware setter) before calling Set.

Useful? React with 👍 / 👎.

[awforsythe]

Fixed with 73a2a76; buffer is now zero-filled to ensure null-termination.

[chatgpt-codex-connector]

Skip RUM context writes when crash handler init failed

This handler only checks _crash_handler for non-null, but Start() keeps _crash_handler even when Initialize() returns false. In that failure mode, context-change messages still invoke SetRumContext; for the in-process backend this attempts file writes despite failed setup (for example after .crashes creation/open failure), causing repeated failed I/O and possible stray temp-file behavior. Track initialization success (or clear _crash_handler on failure) before forwarding context updates.

Useful? React with 👍 / 👎.

[awforsythe]

Fixed with 9dd9597; impl::CrashReporting now discards and destroys its _crash_handler reference if ICrashHandler::Initialize() fails. Once the feature is started, it either has a valid, initialized handler or it has no handler; there is no longer an inbetween state.

[fuzzybinary]

I hate to be that guy but.... are we sure 256 / 260 are the right values here? Is there much harm in doubling it?

[awforsythe]

This is a good point, especially since we ultimately want crash report files to be stored within the user-configurable storage path. I'll bump these buffer sizes for both POSIX and Win32 implementations.

The base branch was changed.

[fuzzybinary]

Other than my nit about file path size, this LGTM.

[awforsythe]

(A forthcoming change which standardizes how we store filesystem paths will address the 256-char limit noted earlier. I'm going to merge this PR as-is, since crash report storage paths will get bumped to a limit of ~512 once they incorporate that change.)