Include frame addresses in SentryFrame when possible

[kabiroberai]

:scroll: Description

This PR adds a -[SentryFrame frameAddress] property which represents the base address of the frame. This address is only included when building stack traces using MachineContext (but this covers most use cases where it's needed). Afaik the backtrace(3) approach doesn't give us enough info to include frame addresses.

:bulb: Motivation and Context

It's really useful to have frame address information when dealing with stack overflow-type crashes. We have some EXC_BAD_ACCESS crashes at Ramp due to stack overflows, because Swift Concurrency has a relatively small stack size of 512K. We're hoping to use this to determine which stack frames/allocations are excessively large and can be shrunk, by computing the difference between consecutive frame addresses.

This PR doesn't aim to serialize the frame address and push it to the backend: that would require additional work on the backend side to handle the frame_addr property. Instead, the changes here give the client the opportunity to consume the frame information (e.g. in beforeSend) and potentially add context such as a list of large frames to their Event.extra.

:green_heart: How did you test it?

• Triggered some stack overflow crashes and ensured that the frameAddress was accessible by the caller.
• Unit tests

:pencil: Checklist

You have to check all boxes before merging:

• [x] I reviewed the submitted code.
• [x] I added tests to verify the changes. (note: let me know if more unit tests are needed and/or where I can add coverage)
• [x] No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• [x] I updated the docs if needed.
• [x] Review from the native team if needed. (requested)
• [x] No breaking change or entry added to the changelog.
• [x] No breaking change for hybrid SDKs or communicated to hybrid SDKs.

:crystal_ball: Next steps

It would be great if we could support this property on the Sentry backend so that clients can consume it without additional code.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.447%. Comparing base (b2c9166) to head (004887a). Report is 105 commits behind head on main.

Additional details and impacted files

@@              Coverage Diff              @@
##              main     #3994       +/-   ##
=============================================
+ Coverage   90.856%   91.447%   +0.590%     
=============================================
  Files          594       594               
  Lines        46392     46534      +142     
  Branches     16620     16647       +27     
=============================================
+ Hits         42150     42554      +404     
+ Misses        4062      3910      -152     
+ Partials       180        70      -110     

Files	Coverage Δ
Sources/Sentry/SentryCrashReportConverter.m	95.765% <100.000%> (+0.027%)	:arrow_up:
Sources/Sentry/SentryCrashStackEntryMapper.m	100.000% <100.000%> (ø)
Sources/SentryCrash/Recording/SentryCrashReport.c	54.207% <100.000%> (+22.158%)	:arrow_up:
...es/SentryCrash/Recording/SentryCrashReportFields.h	75.206% <100.000%> (+8.539%)	:arrow_up:
...ntryCrash/Recording/Tools/SentryCrashStackCursor.c	75.000% <100.000%> (+1.666%)	:arrow_up:
...ntryCrash/Recording/Tools/SentryCrashStackCursor.h	100.000% <ø> (ø)
...ding/Tools/SentryCrashStackCursor_MachineContext.c	91.836% <100.000%> (+0.532%)	:arrow_up:
...egrations/SentryCrash/SentryCrashReportTests.swift	96.363% <100.000%> (+1.014%)	:arrow_up:
...sts/SentryCrash/SentryStacktraceBuilderTests.swift	98.360% <100.000%> (+0.360%)	:arrow_up:
...ts/SentryTests/SentryKSCrashReportConverterTests.m	97.265% <100.000%> (+0.032%)	:arrow_up:

... and 44 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update b2c9166...004887a. Read the comment docs.

[philipphofmann]

Thanks a lot for this proposal @kabiroberai.

It's really useful to have frame address information when dealing with stack overflow-type crashes. We have some EXC_BAD_ACCESS crashes at Ramp due to stack overflows, because Swift Concurrency has a relatively small stack size of 512K. We're hoping to use this to determine which stack frames/allocations are excessively large and can be shrunk, by computing the difference between consecutive frame addresses.

How would you expect Sentry to show this information in an event? I would prefer building a feature that helps all users without having to manually compute differences between frame addresses themselves.

[philipphofmann]

I'm closing this due to inactivity. Please feel free to reopen it with an answer to the question above (https://github.com/getsentry/sentry-cocoa/pull/3994#issuecomment-2117253154).