getsentry
App is killed by watchdog while Setry is symbolicating with `_dyld_get_image_header`
Platform
iOS
Environment
Production
Installed
Swift Package Manager
Version
8.18.0
Did it work on previous versions?
No
Steps to Reproduce
Add Sentry to the app:
SentrySDK.start { (options) in
options.dsn = dsn
options.debug = false
options.enableAutoSessionTracking = false
options.maxBreadcrumbs = 50
options.beforeSend = { event in
// Make sure crash reporting is still enabled.
// If not, returning nil will prevent Sentry from sending the report.
guard isEnabled() else {
LegacyCommon.log.warning("Crash reports sharing is disabled. Won't send error report.", metadata: ["error": "\(String(describing: event.error))"])
return nil
}
// Remove heaviest part of event to make sure event doesn't reach max request size. Can be removed after the issue is fixed on the infra side (INFSUP-682).
if FeatureFlagsRepository.shared.isEnabled(VPNFeatureFlagType.sentryExcludeMetadata) {
event.debugMeta = nil
}
return event
}
shared = SentryHelper(isEnabled: isEnabled)
}
Expected Result
Sentry should work without crashing.
Actual Result
App is killed by watchdog with 0x8BADF00D termination code after 10 seconds hang: <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<ch.protonmail.vpn(F71EC81F-DD3E-43E5-A342-4052E7631350)>:990 exhausted real (wall clock) time allowance of 10.00 seconds
Issue looks very similar to https://github.com/getsentry/sentry-cocoa/issues/1892
Are you willing to submit a PR?
No response
Hello @jaroslavas, thanks for reaching out.
In both crash reports, you can observe a call to onCrash (onCrash (in ProtonVPN) (SentryCrashC.c:95) + 1417080), indicating that the app had already crashed. It's likely that it was hanging for a while before crashing, during which Sentry was attempting to symbolicate the stack trace while the watchdog terminated the app. An alternative scenario could be that something was slowing Sentry from symbolicating the stack trace (though we've never encountered such an issue before), resulting in it taking more than 10 seconds. In both cases, the app had already crashed. It's worth noting that internal symbolication only occurs if SentryOptions.debug is set to true; in production, we don't attempt to symbolicate the stack trace at all.
It's worth noting that internal symbolication only occurs if SentryOptions.debug is set to true; in production
That's weird, as you can see from the code it's options.debug = false
That's weird, as you can see from the code it's options.debug = false
Yes. This is something I had to investigate.
I've identified the problem of why is symbolication running in production for crashes. However, I'm not certain if this is related to your issue. Symbolication of such a small stack frame and number of threads is typically very fast. As I mentioned previously, either the app was hanging for a while when it crashed, or there is another factor slowing down the symbolication process.,
But I believe that ensuring symbolication dont run in production may fix this.
This could be fixed with https://github.com/getsentry/sentry-cocoa/issues/2996.
@philipphofmann #2996 is currently in Backlog with P4 - does it make sense to assign this item an according priority / or tackle this separately from the other?
@philipphofmann #2996 is currently in Backlog with P4 - does it make sense to assign this item an according priority / or tackle this separately from the other?
I think we should first investigate if this issue is related to the other. If yes, then we must bump the prio, IMO.
Hello, this directly affects usability of Sentry for us, an increase in priority would be greatly appreciated.
Closing in favor of https://github.com/getsentry/sentry-cocoa/issues/2996