feat(profiling): Add Perfetto trace format support

[markushi]

This PR adds the ability to ingest binary Perfetto traces (.pftrace) and convert them into the existing Sample v2 JSON format used by Sentry's profiling pipeline. This targets Android
profiling, where Perfetto is the native tracing format.

Key Changes

1. New feature flag organizations:continuous-profiling-perfetto — gates all Perfetto processing.
2. Compound item format via meta_length — profile chunk items can now carry [JSON metadata][binary blob], split at meta_length. This is how Perfetto traces arrive: metadata describes the
   profile, the binary blob is the raw .pftrace.
3. Perfetto → Sample v2 conversion — new relay-profiling/src/perfetto/ module (proto definitions + conversion logic) parses binary Perfetto traces and produces the existing Sample v2
   JSON format.
4. Raw profile passthrough to Kafka — after expansion, the original Perfetto binary is preserved alongside the expanded JSON. Two new fields on ProfileChunkKafkaMessage: raw_profile and
   raw_profile_content_type.
5. New fields on existing structs:
   - Frame.package — library/container path for native/Java frames
   - ProfileMetadata.content_type — carries "perfetto" through the pipeline
   - DebugImage::native_image() constructor — creates debug images from Perfetto mapping data

---

This PR is part of a stack:

• feat(profiling): Add Perfetto trace format support (this PR)
• feat(profiling): Add pipeline workflow to perfetto profiling  #5932
• feat(profiling): Route raw profiles through objectstore service #6025

[markushi]

@sentry review

[cursor]

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

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: First timestamp delta skipped in StreamingProfilePacket processing
  • Removed the 'i > 0' guard so that timestamp_delta_us[0] is now correctly applied to the first sample's timestamp.

Or push these changes by commenting:

@cursor push ab5f3ec796

Preview (ab5f3ec796)

diff --git a/relay-profiling/src/perfetto/mod.rs b/relay-profiling/src/perfetto/mod.rs
--- a/relay-profiling/src/perfetto/mod.rs
+++ b/relay-profiling/src/perfetto/mod.rs
@@ -229,9 +229,7 @@
             Some(Data::StreamingProfilePacket(spp)) => {
                 let mut ts = packet.timestamp.unwrap_or(0);
                 for (i, &cs_iid) in spp.callstack_iid.iter().enumerate() {
-                    if i > 0
-                        && let Some(&delta) = spp.timestamp_delta_us.get(i)
-                    {
+                    if let Some(&delta) = spp.timestamp_delta_us.get(i) {
                         // `delta` is i64 (can be negative for out-of-order samples).
                         // Casting to u64 wraps negative values, which is correct because
                         // `wrapping_add` of a wrapped negative value subtracts as expected.

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[Dav1dde]

A few small things in the conversion code. I tried to mostly follow along logically but the interning and things are quite complicated according to the docs, so I mostly left like small improvements there.

For the actual processing pipeline, see my larger comment in the processor, we need to get some type safety in here. It will also help with code duplication of the duplicated split functions.
Let me know if you want me to help out with that.

[jjbayer]

@Dav1dde and I will go over open comments to see what still needs to be done before we merge this.

[jjbayer]

DebugImage::image_vmaddr can be None, but here we map None to Some(0). Is this semantically correct? Same question for image_addr.

[markushi]

Good point! Yes, all perfetto props are optional. mapping.start.unwrap_or(0) or mapping.end.unwrap_or(0) would be incorrect.

message Mapping {
  ...
  optional uint64 start = 4;
  optional uint64 end = 5;
  optional uint64 load_bias = 6;
  ...
}

[jjbayer]

I feel like it should be possible to represent seen images as references to path vectors instead of allocated Strings, potentially in a newtype with a custom hash or equality implementation.

[sentry]

Bug: The debug image deduplication check is bypassed when mapping.start is None because is_some_and short-circuits, which can lead to duplicate images in the final profile.
_{Severity: MEDIUM}

Suggested Fix

Modify the deduplication logic to correctly handle cases where the image address is None. One approach is to use unwrap_or(0) on image_addr when creating the key for the seen_images set. This ensures that mappings without a start address are still consistently deduplicated based on their code_file and a default address.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: relay-profiling/src/perfetto/mod.rs#L417-L419

Potential issue: In `relay-profiling/src/perfetto/mod.rs`, the deduplication logic for
debug images is bypassed when a mapping's `start` address is `None`. The code uses
`image_addr.is_some_and(...)` which short-circuits when `image_addr` is `None`,
preventing the `seen_images.insert()` call. According to the proto schema,
`mapping.start` is optional and can be `None`. If a trace contains a mapping without a
start address that is referenced multiple times, a new `DebugImage` will be created and
added to the profile for each reference, resulting in duplicate entries and a bloated
output profile.

[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 dd8d044. Configure here.}

[cursor]

Compound profile size limit bypass

Medium Severity

After Perfetto expansion, max_profile_size is applied only to the expanded JSON bytes, not to the rebuilt compound payload that also appends the original binary blob. A chunk within the ingest limit can become roughly twice the configured cap once JSON grows and the raw trace is preserved.

 

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

[sentry]

Bug: The code only attempts to calculate the clock offset from the first ClockSnapshot. If this snapshot is incomplete, subsequent snapshots are ignored, causing the entire trace conversion to fail.
_{Severity: HIGH}

Suggested Fix

Modify the logic to iterate through all ClockSnapshot packets until a valid offset can be calculated, instead of only trying with the first one. Alternatively, collect and merge clock information across multiple snapshots before attempting to calculate the offset.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: relay-profiling/src/perfetto/mod.rs#L251-L253

Potential issue: The trace conversion logic only attempts to extract the clock offset
from the first `ClockSnapshot` packet encountered. The `extract_clock_offset` function
requires both `CLOCK_REALTIME` and `CLOCK_BOOTTIME` to be present in the same snapshot.
If the first snapshot is incomplete (lacking one of these clocks), `clock_offset_ns`
remains `None`. Because of the `if clock_offset_ns.is_none()` guard, all subsequent
`ClockSnapshot` packets are then ignored, even if they contain the necessary
information. This leads to a failure when the code later requires a valid
`clock_offset_ns`, causing the entire trace processing to fail for valid Perfetto traces
that happen to start with an incomplete clock snapshot.

[sentry-warden]

Unbounded callstack depth enables CPU exhaustion DoS in Perfetto trace parsing

A crafted Perfetto trace can embed a single callstack with ~2 million frame_ids within the allowed 4 MB per-packet limit. When MAX_SAMPLES (100,000) samples all reference this callstack, resolve_callstack hashes a 2M-entry Vec<usize> for every sample via stack_index.get(), yielding O(200 billion) CPU operations from a ~5 MB input on any relay with ContinuousProfilingPerfetto enabled. Add a per-callstack frame depth cap (e.g., 2,000) at merge or resolution time.

Evidence

• Callstack.frame_ids is Vec<u64> with packed = "false" (proto.rs); a 4 MB packet fits ~2 M frame IDs.
• InternTables::merge at lines 182–183 calls .extend(callstacks.into_iter()...) with no check on c.frame_ids.len().
• resolve_callstack (line 346) does Vec::with_capacity(callstack.frame_ids.len()), iterates all frame_ids, then calls ctx.stack_index.get(&resolved_frame_indices) — an O(n) hash over the full Vec.
• With 100,000 PerfSample packets (each ~4 bytes) pointing to the same deep callstack, total work is O(MAX_SAMPLES × frame_ids.len()) = O(200 B) operations, fitting inside the 50 MiB max_profile_size limit.
• The feature-flag check in process_compound_item (process.rs line ~123) gates this path, so exploitation requires ContinuousProfilingPerfetto to be enabled — feasible for any project using the new Android Perfetto profiling.

_{Identified by Warden security-review · WJF-LPZ}