fix(native): read frame records at pointer width in the crash daemon's FP walk

[GLinnik21]

Summary

read_stack_value in the native backend's crash daemon bounds-checks and copies sizeof(uint64_t) bytes regardless of the target's pointer size, and the frame-pointer walk steps to the return address with the same constant. On a 32-bit target every read therefore spans two stack slots: the high half of each saved_fp / return_addr is the neighbouring word, the return address is read from the wrong slot, and the last legitimate frame record fails the bounds check.

This reads a uintptr_t and widens it to uint64_t (so the value is endian-independent), and steps by pointer size. On 64-bit targets the size and offsets are unchanged. While here, the range check is done by subtraction rather than addr + size, since addr is a frame pointer from a crashed process and a corrupted value near the top of the address space would wrap the sum past the naive comparison.

Scope

This is the daemon's frame-pointer fallback. On Linux the signal handler captures a libunwind backtrace first and build_stacktrace_for_thread returns that when it is non-empty; the FP walk runs when that capture is unavailable or empty (for example a build that disables in-process libunwind, or unw_init_local2 failing). Within that fallback, the pointer-width reads are wrong on every 32-bit target. On ARM32 this alone is not sufficient for GCC-built frames — see #2053, which is stacked on this PR.

Verification

• ARM32 hardware (LG webOS 4.x television, Cortex-A9, glibc 2.24, in-process libunwind disabled so the FP fallback is exercised): with this fix alone, a SIGABRT in a rustc-built application walks gsignal ← plex_run ← __libc_start_main (3 named frames); a GCC-built chain with frame pointers still stops after one real frame followed by a stack address, which is the record-shape problem feat(native): ARM32 registers and both frame-record shapes in the crash daemon #2053 addresses.
• sentry-crash cross-compiles for arm-linux-gnueabi (GCC 12); the SDK and daemon build on macOS arm64 with SENTRY_BACKEND=native; clang-format clean.
• No automated 32-bit coverage of the native backend runs in CI today (the ARM32 job runs under TEST_QEMU, which skips the native integration suite), and read_stack_value is a static function inside the daemon with no unit-test seam, so this PR adds no test. Happy to add one if there is a preferred shape for daemon-internal tests.

[Copilot]

🟡 Changes recommended

The updated read_stack_value implementation should avoid uint64_t overflow in bounds checks and use an endian-safe widening strategy when copying uintptr_t into uint64_t.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR fixes the crash daemon’s frame-pointer fallback stack walking to read frame records at the target’s pointer width, preventing incorrect slot reads and bounds-check failures on 32-bit targets while preserving 64-bit behavior.

Changes:

• Update read_stack_value to bounds-check and copy sizeof(uintptr_t) bytes (instead of always sizeof(uint64_t)).
• Step from saved FP to return address using pointer-sized offsets in the FP walk.
• Document the fix in CHANGELOG.md.

File summaries

File	Description
src/backends/native/sentry_crash_daemon.c	Switch stack reads/FP-walk offsets to pointer width for correct 32-bit frame record decoding.
CHANGELOG.md	Add an Unreleased fix entry describing the pointer-width FP-walk change.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[GLinnik21]

Addressed the review: read_stack_value now range-checks by subtraction (no addr + size that could wrap for a corrupted frame pointer) and reads into a uintptr_t before widening to uint64_t, so the value is endian-independent. Re-verified on ARM32 hardware; macOS native-backend build and arm-linux-gnueabi cross-compile still clean.

[jpnurmi]

Thank you! LGTM 👍

[codecov]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.34%. Comparing base (d95373f) to head (1437550).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2052      +/-   ##
==========================================
- Coverage   74.38%   74.34%   -0.04%     
==========================================
  Files         103      103              
  Lines       26672    26676       +4     
  Branches     4853     4853              
==========================================
- Hits        19839    19833       -6     
- Misses       5487     5506      +19     
+ Partials     1346     1337       -9     

🚀 New features to boost your workflow:

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