sentry-cocoa
sentry-cocoa copied to clipboard
getsentry
Don't symbolicate stacktrace during crash
Description
At the moment, we're attempting to symbolicate the stacktrace during crashes using a custom function instead of dladdr, in order to ensure async safety. However, this custom function is slower and doesn't work with Swift async stitching, as noted in this comment.
One alternative solution is to serialize the addresses and symbolicate them in the next session, since we only capture the crash data during the next session anyway
Solving this issue might also fix:
- https://github.com/getsentry/sentry-cocoa/issues/3687
One alternative solution is to serialize the addresses and symbolicate them in the next session, since we only capture the crash data during the next session anyway
The problem is that the addresses can change on the next run, if I'm not mistaken. Maybe we can try a similar approach as we do for MetricKit: https://github.com/getsentry/sentry-cocoa/blob/fd6a31ce3940224432d2ece19de8c052bec3c3d2/Sources/Sentry/SentryMetricKitIntegration.m#L401-L447
The problem is that the addresses can change on the next run, if I'm not mistaken. Maybe we can try a similar approach as we do for MetricKit:
AFAYK the symbols included in a binary are linked to specific memory locations in the binary. Only if the app install a new version we would have a problem, which is a reasonable tradeoff.
We should consider completely removing sentrycrashdl_dladdr / local symbolication because isn't async safe and causes problems such as deadlocks https://github.com/getsentry/sentry-cocoa/issues/4056 and the watchdog killing apps using the Cocoa SDK https://github.com/getsentry/sentry-cocoa/issues/3687.
https://github.com/getsentry/sentry-cocoa/blob/d9280eec4f311096709ba84fc6a5d04423503c6c/Sources/SentryCrash/Recording/Tools/SentryCrashDynamicLinker.h#L116
We should consider completely removing sentrycrashdl_dladdr
We have decided to follow this approach.
The problem is that the addresses can change on the next run, if I'm not mistaken. Maybe we can try a similar approach as we do for MetricKit:
AFAYK the symbols included in a binary are linked to specific memory locations in the binary. Only if the app install a new version we would have a problem, which is a reasonable tradeoff.
While it is true that the symbols are linked to specific memory locations in the binary, the memory addresses will change due to Address Space Layout Randomization. The binary will be loaded to a different address each time.
From https://support.apple.com/fr-fr/guide/security/sec15bfe098e/web
Address Space Layout Randomization
Address Space Layout Randomization (ASLR) helps protect against the exploitation of memory corruption bugs. Built-in apps use ASLR to help randomize all memory regions upon launch. In addition to work upon launch, ASLR randomly arranges the memory addresses of executable code, system libraries, and related programming constructs, further reducing the likelihood of many exploits. For example, a return-to-libc attack attempts to trick a device into executing malicious code by manipulating memory addresses of the stack and system libraries. Randomizing the placement of these makes the attack more difficult to execute, especially across multiple devices. Xcode, and the iOS or iPadOS development environments, automatically compile third-party programs with ASLR support turned on.
While it is true that the symbols are linked to specific memory locations in the binary, the memory addresses will change due to Address Space Layout Randomization. The binary will be loaded to a different address each time.
I believe this obscured from the app itself, otherwise no symbolication would ever work. But this does not matter any more, we would symbolicate the crash locally anymore.