Post

Replies

Boosts

Views

Activity

Crash in connection loader from CFNetwork with stack traces referring to internal Apple SDKs
We found there is a significant crash reports (most of them are from iOS 17, the rest are iOS 16 and 15) comes from network loader from CFNetwork. Apparently it seems there are two types of crashes if we checked from the stack trace, the one we found from both Xcode organizer and 3rd party crash reporter is referring to URLConnectionLoader::loadWithWhatToDo and the other one from our 3rd party crash reporter (didn’t found the report from Xcode organizer) referring to _CFURLResponseCreateFromArchiveList (this one only happened on iOS 17.5 and later devices). It seems that they are both kinda similar which might point to the same root cause. From what I’ve seen, we never touch the lower level API directly, we usually use the URLSession to manage our API request. The crashed stack trace also didn’t give any indication about which of our app code that triggered the crash, it only shows calls to Apple’s internal SDKs so we are unsure how to approach this issue meanwhile the crash event already reached 800+ in the last 30 days. Unfortunately, we cannot reproduce the issue as the stack trace itself seems unclear to us. I have submitted a report through feedback assistant with number: FB14679252. Would appreciate if anyone can give any advice on what we can do to avoid this in the future and probably any hint on why it could happened. Hereby I attached the crash reports that we found each from Xcode crash report and our 3rd party crash reporter (the report said it crashed on com.apple.CFNetwork.LoaderQ) so you could get a glimpse of the similarity. Xcode crash report xcode crash report.crash 3rd party crash report 3rd party crash report.txt
4
0
426
Aug ’24
Crash when accessing Core Data because file couldn't be opened
We have a crash regarding to Core Data access that was not reproducible in our side but the crash count keeps increasing with the last stack trace is assertionFailure from Apple internal SDK. The last stack trace before the assertionFailure by system is our code initializing CoreData in DataContainer.init(name:bundle:inMemory:) where we will try to access CoreData and the error message we found from our 3rd party crash reporter is something like this DataStore/DataContainer.swift:30: Fatal error: Unresolved error Error Domain=NSCocoaErrorDomain Code=256 "The file “Content.sqlite” couldn’t be opened. UserInfo={NSFilePath=/var/mobile/Containers/Data/Application/9DBF262C-851A-486B-90CC-4397A8896525/Library/Application Support/Content.sqlite, NSSQLiteErrorDomain=13}, ["NSSQLiteErrorDomain": 13, "NSFilePath": /var/mobile/Containers/Data/Application/9DBF262C-851A-486B-90CC-4397A8896525/Library/Application Support/Content.sqlite] That sqlite file is supposed to be file used by Core Data (since we have no other code that access it) and we are quite confused on why sometimes the CoreData cannot be accessed with that kind of error message. So far, we still have no idea to reproduce it and what do to resolve it. I have submitted the report with bug number: FB14433998 I attached an example of the crash report here too. Please gave us insight on why it happened and how we can prevent it from happening again. crash log 1.crash
1
0
346
Jul ’24
Test
This is a testing thread to try attaching crash report that was unable to be attached few days earlier when I tried to create a new thread. This test is requested by Apple DTS to help isolating the issue. For more context: https://forums.developer.apple.com/forums/thread/747480 Crash report: crash-log-iOS-17.crash
0
0
599
Mar ’24
Crash in background for iOS 17.3.0 and later devices
We found crash reports from Xcode organizer about some crashes happening only in iOS and iPadOS version 17.3.0 and later across all our releases mostly in background state related to Network SDK. Unfortunately, we are unable to reproduce the issue. On the crashed thread, it seems to refer to process from Network SDK but we never import and use it directly in our project. Most of the functions found in the main thread in the crash report can't be accessed from the project, it seems to be internal framework calls in iOS SDK. The crash pointing to this line of code: nw_protocol_error Bug number: FB13661192 Somehow I cannot attach any crash report here, it always return error This post contains sensitive language. Please revise it in order to continue. whenever I try to submit it. If I remove it, I can submit the post.
4
0
853
Feb ’24
AVPlayerItemNewErrorLogEntry notification not triggered when observed
We are currently observing AVPlayerItemNewErrorLogEntry notification event to track error from AVPlayer which later will be written in our logs to help us identify issue in production. But when we checked again, turns out currently the notification is not getting triggered causing many missing crucial information in our logging to debug issue that occurred related to AVPlayer as we need the errorComment information inside the error log event. Meanwhile, the accessLog event get triggered just fine. But if we check the error directly, it said that the errorLog is not empty and we can retrieve the errorLog manually by accessing the errorLog from AVPlayer.currentItem directly. (can refer to the screenshot below regarding the error from console) Is there something wrong with our implementation or it is indeed a bug from Apple ? We already filed bug report with number: FB12580746 and we are using Xcode 14.3.1.
0
0
513
Jul ’23
Crash on iOS 15 devices happens mostly in background
Hi, Our application is currently crashing in production, only for users with iPhone and iPad running iOS and iPadOS 15 through all releases. Unfortunately, we cannot reproduce the issue, neither through direct build from Xcode or using build from app store, so it seems to happen intermittently. From third party crash analytics, it seems to happens mostly of background and they highlighted this as the issue. Fatal Exception: NSInvalidArgumentException -[_NSXPCDistantObject cleanupWithCompletionHandler:]: unrecognized selector sent to instance 0x2813293b0 From the Xcode crashlogs, it highlighted this which intrigue me a bit and it also exists on the stack trace from the third party (you can see they call a same function __cleanupWithCompletionHandler there). 5 Pegasus __58-[PGPictureInPictureProxy __cleanupWithCompletionHandler:]_block_invoke It seems that the crash happens probably because some process related to PIP feature that triggered this function that is handled by Pegasus framework. Any idea why this happens and is there anything i can do to prevent the crashes from happening again ? crash-log-iOS-15.crash
17
1
9.2k
Jan ’22