test(benchmark): crash handler stack usage

[jpnurmi]

Measure how much stack each crash backend uses while processing a fatal error.

Boring details for the curious

When a thread first enters crash handling, the fixture fills a 12 KiB local array with a recognizable byte pattern. The helper then returns, leaving the pattern in stack space available for reuse. As the real crash handler runs, its call frames overwrite that pattern.

Before the thread leaves crash handling, the fixture scans the remaining pattern. The deepest overwritten position is reported as [STACK] N bytes. Nested entries on the same thread form one measurement, while separate handler intervals or threads may produce multiple values. The benchmark records the largest value because these are independent stack peaks, not additive memory usage.

Crash callbacks may run on alternate signal stacks as small as 16 KiB. Painting 12 KiB leaves the remaining 4 KiB for the signal frame and callback machinery while paint_stack is active. Painting the full 16 KiB would risk overflowing the stack before measurement begins.

Add integration callbacks around each backend's crash-handling work so the fixture can apply the same measurement consistently. These callbacks must remain async-signal-safe because some backends invoke them from a signal handler.

Use a dummy custom HTTP client so the measured path includes the HTTP transport's crash-time queue drain without depending on network I/O.

Share the SDK target-property helper used by source-compiling test targets instead of duplicating it in each CMake file.

The stack usage measurements are published in benchmark charts and monitored over time:

To inspect stack usage locally:

$ cmake -S . -B build -DSENTRY_BACKEND=inproc -DSENTRY_BUILD_TESTS=ON -DSENTRY_BUILD_BENCHMARKS=ON
$ cmake --build build --target sentry_stack_usage
$ ./build/tests/fixtures/stack_usage/sentry_stack_usage
[...]
[STACK] 0 bytes
[...]
[STACK] 7512 bytes
[STACK] 336 bytes
Segmentation fault (core dumped)

The number and values of the measurements depend on the backend and platform. The final crash is intentional.

Separately, add make stack-frames for manual inspection of the functions compiled into libsentry. It builds the selected backend with -fstack-usage and prints the 20 largest compiler-reported function frames. This does not measure a call chain or runtime high-water mark and is not published as a benchmark result.

$ make stack-frames SENTRY_BACKEND=inproc N=50
4192    src/unwinder/sentry_unwinder_libunwind.c:66:5:find_mem_range_from_fd    static
[...]

Close: #997

[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.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

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

[codecov]

Codecov Report

❌ Patch coverage is 37.20930% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.28%. Comparing base (989606e) to head (8a1133b).

Additional details and impacted files

@@                        Coverage Diff                         @@
##           jpnurmi/test/benchmark-libsize    #2029      +/-   ##
==================================================================
+ Coverage                           74.27%   74.28%   +0.01%     
==================================================================
  Files                                 104      104              
  Lines                               26627    26670      +43     
  Branches                             4844     4850       +6     
==================================================================
+ Hits                                19777    19813      +36     
- Misses                               5502     5506       +4     
- Partials                             1348     1351       +3     

🚀 New features to boost your workflow:

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