(POC) feat: Sentry native crash backend

[mujacica]

• Sentry native crash backend
• Out-of-process daemon/handler
• MacOS/Android/Windows/Linux support
• Integration with external crash reporter
• IPC/SHM/Signaling multi-platform implementation
• Minidump writers for all platforms
• In-process option (process_crash function)
• Different options for Minidump sizes
• Full sentry-codebase integration
• Sentry logger integration
• Sentry debug-flags integration

[mujacica]

@sentry review

[mujacica]

@sentry review

[mujacica]

@sentry review

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[sentry]

Bug: The MAX_STACK_SIZE for macOS minidumps is hardcoded to 64KB, while the signal handler captures up to 512KB, leading to truncated stack traces.
_{Severity: HIGH}

Suggested Fix

In src/backends/native/minidump/sentry_minidump_macos.c, change the definition of MAX_STACK_SIZE to use the full captured size. For example, change const size_t MAX_STACK_SIZE = SENTRY_CRASH_MAX_STACK_CAPTURE / 8; to const size_t MAX_STACK_SIZE = SENTRY_CRASH_MAX_STACK_CAPTURE; to align with the signal handler's behavior and other platforms.

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: src/backends/native/minidump/sentry_minidump_macos.c#L531

Potential issue: In `sentry_minidump_macos.c`, the `MAX_STACK_SIZE` for stack capture is
set to `SENTRY_CRASH_MAX_STACK_CAPTURE / 8`, which evaluates to 64KB. However, the
signal handler in `sentry_crash_handler.c` is configured to capture up to
`SENTRY_CRASH_MAX_STACK_CAPTURE` (512KB). This discrepancy causes the minidump writer to
discard most of the captured stack data. As a result, applications on macOS, especially
those with deep call stacks, will have incomplete stack traces in their crash reports,
hindering debugging efforts. This is inconsistent with the Linux implementation which
uses a much larger stack size.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[cursor]

Cursor Bugbot has reviewed your changes and found 4 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

ELF note parsing bounds check ignores alignment padding

Low Severity

The bounds check at line 839 uses unaligned sizes (nhdr->n_namesz + nhdr->n_descsz) but line 846 advances ptr by the aligned name size (((nhdr->n_namesz + 3) & ~3)). This mismatch means a malformed ELF file with small n_namesz requiring alignment padding could pass the bounds check but then cause a buffer over-read when copying n_descsz bytes at line 849. For example, with n_namesz=1, n_descsz=10, and 11 remaining bytes: the check passes (1+10≤11), but after aligned advance of 4 bytes, only 7 bytes remain for a 10-byte read.

 

[cursor]

Mach-O load command parsing lacks bounds validation

Low Severity

The Mach-O load command parsing loop iterates up to header.ncmds times without verifying that ptr remains within commands_buf. Before reading cmd->cmd and cmd->cmdsize at line 253-255, there's no check that ptr + sizeof(struct load_command) is within bounds. Additionally, ptr += cmd->cmdsize at line 262 could advance past the buffer if cmdsize is corrupted in a malformed Mach-O file. A malformed binary could cause out-of-bounds memory reads.

 

[cursor]

Missing bounds check for crash context array indices

Medium Severity

The minidump writers use module_count and num_threads from the crash context to iterate over fixed-size arrays (modules[SENTRY_CRASH_MAX_MODULES] with 512 elements and threads[SENTRY_CRASH_MAX_THREADS] with 256 elements), but never validate these counts against the array bounds. If the crash context contains values exceeding these limits (due to signal handler bugs or shared memory corruption), the code performs out-of-bounds array access. For example, macOS write_module_list_stream accesses writer->crash_ctx->modules[i] where i can reach module_count - 1 without checking if it exceeds 511.

Additional Locations (2)

• src/backends/native/minidump/sentry_minidump_linux.c#L1065-L1070
• src/backends/native/minidump/sentry_minidump_macos.c#L669-L678

 

[cursor]

Memory64 list base_rva uses wrong field size

Low Severity

The minidump_memory64_list_t structure defines base_rva as minidump_rva_t (32-bit uint32_t), but per Microsoft's minidump specification, MINIDUMP_MEMORY64_LIST.BaseRva is RVA64 which is 64-bit. This format mismatch would produce invalid minidumps if this type were used to write Memory64 streams. While currently unused in the implementation, the definition is incorrect and could cause data corruption if used in the future.