Crash reports for app extensions not discovered
Platform
iOS
Installed
CocoaPods
Version
7.9.0
Steps to Reproduce
Start SentrySDK with options and options.debug = true. Simulate a crash with SentrySDK.crash(), restart the target, logs will indicate that 0 crash logs are uploaded.
Expected Result
I would expect that the SentrySDK finds the crash reports for my app extension and push them to the Sentry instance.
Actual Result
2022-02-02 21:13:39.356409+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Sent 0 crash report(s)
2022-02-02 21:13:39.356967+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryCrashIntegration
2022-02-02 21:13:39.357081+0100 StackFilesExtension[27589:2879105] Sentry - debug:: No tracesSampleRate and tracesSampler set. Will not track slow and frozen frames.
2022-02-02 21:13:39.357183+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryFramesTrackingIntegration
2022-02-02 21:13:39.357358+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Add breadcrumb: <SentryBreadcrumb: 0x60000239f440>
2022-02-02 21:13:39.358085+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryAutoBreadcrumbTrackingIntegration
2022-02-02 21:13:39.358221+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Reading timestamp of last in foreground at: /Users/jbehrens/Library/Developer/CoreSimulator/Devices/34218245-8B17-4D59-8E81-2876B839C4C8/data/Containers/Data/PluginKitPlugin/6D7D12E7-FD57-4EE7-BBC6-D1C4666F7A90/Library/Caches/io.sentry/037f4af6271b8e43b2110d85bfedc06989fb2984/lastInForeground.timestamp
2022-02-02 21:13:39.358397+0100 StackFilesExtension[27589:2879105] Sentry - debug:: No lastInForeground found.
2022-02-02 21:13:39.358545+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Reading from session: /Users/jbehrens/Library/Developer/CoreSimulator/Devices/34218245-8B17-4D59-8E81-2876B839C4C8/data/Containers/Data/PluginKitPlugin/6D7D12E7-FD57-4EE7-BBC6-D1C4666F7A90/Library/Caches/io.sentry/037f4af6271b8e43b2110d85bfedc06989fb2984/session.current
2022-02-02 21:13:39.358745+0100 StackFilesExtension[27589:2879105] Sentry - debug:: No cached session to close.
2022-02-02 21:13:39.358880+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryAutoSessionTrackingIntegration
2022-02-02 21:13:39.359026+0100 StackFilesExtension[27589:2879105] Sentry - debug:: No tracesSampleRate and tracesSampler set. Will not track app start up time.
2022-02-02 21:13:39.359143+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryAppStartTrackingIntegration
2022-02-02 21:13:39.359325+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryOutOfMemoryTrackingIntegration
2022-02-02 21:13:39.359459+0100 StackFilesExtension[27589:2879105] Sentry - debug:: No tracesSampleRate and tracesSampler set. Will not start SentryPerformanceTrackingIntegration.
2022-02-02 21:13:39.359583+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryPerformanceTrackingIntegration
2022-02-02 21:13:39.359766+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Not going to enable NetworkTracking because isTracingEnabled is disabled.
2022-02-02 21:13:39.360465+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryNetworkTrackingIntegration
2022-02-02 21:13:39.360627+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Not going to enable FileIOTracking because tracing is disabled.
2022-02-02 21:13:39.360755+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Integration installed: SentryFileIOTrackingIntegration
2022-02-02 21:13:39.592786+0100 StackFilesExtension[27589:2879697] [boringssl] boringssl_metrics_log_metric_block_invoke(151) Failed to log metrics
2022-02-02 21:13:39.595503+0100 StackFilesExtension[27589:2879697] [boringssl] boringssl_metrics_log_metric_block_invoke(151) Failed to log metrics
2022-02-02 21:13:39.647703+0100 StackFilesExtension[27589:2879107] Sentry - debug:: Add breadcrumb: <SentryBreadcrumb: 0x600002398180>
2022-02-02 21:13:39.647703+0100 StackFilesExtension[27589:2879105] Sentry - debug:: Add breadcrumb: <SentryBreadcrumb: 0x6000023948c0>
2022-02-02 21:13:39.721798+0100 StackFilesExtension[27589:2879699] [boringssl] boringssl_metrics_log_metric_block_invoke(151) Failed to log metrics
2022-02-02 21:13:39.751978+0100 StackFilesExtension[27589:2879700] Sentry - debug:: Add breadcrumb: <SentryBreadcrumb: 0x6000023907c0>```
Hi @jbehrens94 Thanks for letting us know.
What kind of extension are you creating?
Hi @brustolin,
Thank you for the quick response! I'm building a FileProvider extension.
I was just thinking, for the main app I'm using Crashlytics. For the FileProvider extension, I'm using Sentry. I'm not too up to date on how crash reports work and such, but could it be that Crashlytics is reporting them before Sentry has a change to get them?
but could it be that Crashlytics is reporting them before Sentry has a change to get them?
I don't think so. We use different mechanisms to do it.
Is your project open source? It would be easier if I could download it to test.
I could provide a sample project later today, if that works for you?
That would be perfect. Thanks!!
Hi @brustolin,
I pushed a very very very small repository here. I've added Sentry as a dependency with Cocoapods.
Reproduction steps:
- In Xcode run the FileProviderTest scheme (not the UI or main app). When asked, select the Files app to run this target with.
- In the Files app, select "More locations" and enable the FileProvider.
- Open the provider and see the crash in the console.
- In Xcode, re-run the scheme and see in the debug logs that Sentry uploaded 0 crash logs.
Thanks @jbehrens94. This is a little deeper than I have thought. I'm adding this to our backlog, but unfortunately I can't give you a ETA right now.
You're welcome! Thank you for your time and help and I look forward to use Sentry in app extensions, too. :)
Might be related to https://github.com/getsentry/sentry-cocoa/issues/1679.
How might it be related to #1679, @philipphofmann? As far as I know, I just crash, but don't get out-of-memory. I'm curious to see how it's possibly related. :)
It could be that SentryCrash can't find the crash report. Your logs also contain Sent 0 crash report(s) as do the logs of https://github.com/getsentry/sentry-cocoa/issues/1679.
@philipphofmann @brustolin Any update for this issue? Maybe it'd be good to collect some pointers in this issue so that I could have a peek myself, debug and make a PR if I can figure it out.
Unfortunately we don't have a ETA. We would appreciate if you want to give it a try and create a PR.
@brustolin Would you have any pointers for me to start researching this issue?
Not really, no. I did a little research about this problem without any success.
@brustolin I just checked out v7.15 from my fork and put that in my test project linked in a previous comment. After restarting the app a couple of times I saw that events like EXC_BAD_ACCESS would get sent to Sentry and I'm seeing them on my panel now.
Did something change between 7.9.0 and 7.15.0? I'm not quite sure if the behaviour is correct now, but it looks like it. Does this look like a valid crash reporting is sent?
Hey @jbehrens94,
this method creates the directory for crash reports https://github.com/getsentry/sentry-cocoa/blob/e5a906bf07e0793d1d538ac33e2869efd0b668be/Sources/SentryCrash/Recording/SentryCrashC.c#L116
It could be that this somehow doesn't work properly for app extensions.
Yes, one of the following PRs might have fixed this issue
- https://github.com/getsentry/sentry-cocoa/pull/1735
- https://github.com/getsentry/sentry-cocoa/pull/1734
- https://github.com/getsentry/sentry-cocoa/pull/1658
Hey @jbehrens94,
this method creates the directory for crash reports
https://github.com/getsentry/sentry-cocoa/blob/e5a906bf07e0793d1d538ac33e2869efd0b668be/Sources/SentryCrash/Recording/SentryCrashC.c#L116
It could be that this somehow doesn't work properly for app extensions.
Hi @philipphofmann,
I'm seeing for the Simulator that the folder gets created on disk, but it doesn't get populated with crash reports. Sometimes I do see a JSON file being written into {installPath}/Reports/, but it doesn't get sent to Sentry. Just an FYI.
Sometimes I do see a JSON file being written into {installPath}/Reports/, but it doesn't get sent to Sentry. Just an FYI.
@jbehrens94, do the JSON reports stay in the folder, or do they disappear after starting the app? Could you share one of the reports here? Please make sure it doesn't contain PII if you do.
Using 7.26.0 I am seeing crash reports getting sent without problem: Sent 1 crash report(s), and indeed I see the crash in Sentry. @jbehrens94 mentioned that he saw crash reports coming in using 7.15.0 as well. I'm seeing JSON files getting written to disk without any problem. So, to me it seems we can close this issue?

Closing this issue as it seems to have been fixed some time ago.