Same issue here. Interestingly only my SPM test target fails. My library target succeeds.
datwelk
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Sounds plausible. No luck resolving it. I still see it, but not very often. I know on my phone that when I kill an app and immediately relaunch it, this app always crashes (regardless of which app). Perhaps it's this crash that is being logged? Clearly this is an issue in iOS. Is this the crash that you refer to?
My hypothesis is that UIAppearance selectors cause this crash when an image constructed with +[UIImage new] is used as the argument value in an appearance selector. I will change this to using a transparent PNG to see if this solves the crash. It will take some time though (maybe 2 months) before users have updated the application.
No. Still occuring in iOS 16.4.1.
Bug number is 10663350 (sorry only got around filing one just now). I have shared extra information regarding a thread that contains application-specific code, that is consistently in a mach_exception_callback function of PLCrashReporter. I see the same in thread 8 in a similar crash report here: https://developer.apple.com/forums/thread/112915. Perhaps the issue is in PLCrashReporter, or in the interplay between PLCrashReporter and CFNetwork? Is there any progress on this issue from Apple side?
Thank you for the analysis. Is there any news regarding this issue? We still seem to experience it on the latest iOS release (15.4.1). Are there any known workarounds? We are considering reimplementing our networking stack using SwiftNIO, but this will take some time
Looking at crash logs from our other application that shares a big chunk of the codebase of this one, I see more SIGSEGV crashes caused by _dispatch_source_set_runloop_timer_4CF. For example, in the callstack of another SIGSEGV crash I see _CFURLStorageSessionCopyCache, followed by 3x _CFNetworkSetATSContext, after which a crash occurs in _dispatch_source_set_runloop_timer_4CF. Without knowing the implementation of that function, could it be that some GCD resources have been exhausted, resulting in the segmentation violation?
Many thanks for your swift reply. I have attached updated crash logs to a separate post in this topic. Please let me know if there is anything else I can do.