Getting CFNetwork, CoreMotion Crashes after releasing iOS Application - ios

After releasing my ios application, I started to get lots of crash such as CFNetwork, CoreMotion etc. And then I thought, I did something wrong on my project. I sent a new build after reversed everything what I did. But problem is I am getting same crashes. There is no difference between previous build which I do not get these errors and current build. How is it possible that? Is there anyone who has an idea? I am attaching the most crash logs that I get. Interesting thing is I am NOT getting this crash on ios latest version (15.4.1). I am getting this crash only below ios 15.4.1. I am not able to reproduce on my side. I am sharing firebase logs.
com.apple.NSURLConnectionLoader
0 libsystem_kernel.dylib 0x1504 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x1b9c mach_msg + 76
2 CoreFoundation 0x7738 __CFRunLoopServiceMachPort + 372
3 CoreFoundation 0xba2c __CFRunLoopRun + 1212
4 CoreFoundation 0x1f468 CFRunLoopRunSpecific + 600
5 CFNetwork 0x27a510 _CFURLStorageSessionCopyIdentifier + 59784
6 Foundation 0x683fc __NSThread__start__ + 808
7 libsystem_pthread.dylib 0x19a4 _pthread_start + 148
8 libsystem_pthread.dylib 0xea0 thread_start + 8

Related

What is the cause of an iOS 12 ".cold.1" viewcontroller crash, pertaining to CoreData?

I have a crash in my iOS application that appears to be unique to iOS 12 only. This crash started happening when Xcode 11.3 was released.
The stack trace is as follows
Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x20148b0dc __pthread_kill + 8
1 libsystem_pthread.dylib 0x201504094 pthread_kill$VARIANT$mp + 380
2 libsystem_c.dylib 0x2013e3ea8 abort + 140
3 Field Portal 0x100d9cc74 -[InventoryViewController initializeData].cold.1 + 4305833076
4 Field Portal 0x100c1227c -[PSICoreDataController saveViewContext] + 73 (PSICoreDataController.m:73)
5 CoreData 0x2044832b0 developerSubmittedBlockToNSManagedObjectContextPerform + 156
6 libdispatch.dylib 0x20132d7d4 _dispatch_client_callout + 16
7 libdispatch.dylib 0x2012db008 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1068
8 CoreFoundation 0x201880b20 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
9 CoreFoundation 0x20187ba58 __CFRunLoopRun + 1924
10 CoreFoundation 0x20187afb4 CFRunLoopRunSpecific + 436
11 GraphicsServices 0x203a7c79c GSEventRunModal + 104
12 UIKitCore 0x22e0dcc38 UIApplicationMain + 212
13 Field Portal 0x100c1939c main + 14 (main.m:14)
14 libdyld.dylib 0x20133e8e0 start + 4
InventoryViewController is a very specific view controller nested VERY deeply within the application, and is not used by any user of my app (yes, I know this).
It seems like what is happening is when I call a save on my primary viewContext, the iOS runtime is somehow initializing InventoryViewController on its own, triggering this function, which results in a crash.
InitializeData itself merely executes a simple NSFetchRequest against the main CoreData context, and if I access this view through normal means, it will not crash on the impacted hardware/OS.
What I don't understand is WHY is iOS doing this? This view controller is never accessed by users, and it is never called directly by any of my code.
Furthermore, this code has not changed in almost a calendar year, and suddenly started happening only on these new builds, and only on iOS 12.
I've found this issue impossible to debug, and would welcome any insight on methodologies for research and analysis on how I can figure out what the cause of this issue is.

Crash on iOS > TCCAccessRequest_block_invoke_2.8

I've got an error in my app (iOS 8 to iOS 11) :
Crashed: com.apple.root.default-qos
0 libsystem_kernel.dylib 0x1839a00a8 __abort_with_payload + 8
1 libsystem_kernel.dylib 0x18399b100 abort_with_payload_wrapper_internal + 100
2 libsystem_kernel.dylib 0x18399b12c system_set_sfi_window + 10
3 TCC 0x1868ed99c __TCCAccessRequest_block_invoke_2.85 + 222
4 TCC 0x1868ed8bc __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 706
5 TCC 0x1868f113c __tccd_send_block_invoke + 316
6 libxpc.dylib 0x183aeda0c _xpc_connection_reply_callout + 60
7 libxpc.dylib 0x183aed948 _xpc_connection_call_reply_async + 88
8 libdispatch.dylib 0x18380d758 _dispatch_client_callout3 + 16
9 libdispatch.dylib 0x183825060 _dispatch_mach_msg_async_reply_invoke$VARIANT$mp + 324
10 libdispatch.dylib 0x183813f54 _dispatch_queue_override_invoke$VARIANT$mp + 400
11 libdispatch.dylib 0x18381a1c8 _dispatch_root_queue_drain + 596
12 libdispatch.dylib 0x183819f10 _dispatch_worker_thread3 + 120
13 libsystem_pthread.dylib 0x183ab3130 _pthread_wqthread + 1268
14 libsystem_pthread.dylib 0x183ab2c30 start_wqthread + 4
I've read some subjects about errors like this one. Each time, people says that comes from Permissions in infos.plist.
App uses camera, library, geolocation. So I add :
Privacy - Camera Usage Description
Privacy - Location When in Use
Privacy - Photo Library Usage Description
But there is always the same problem.
I add Microphone usage in plist, but same crash occurs.
I don't understand the crash. On my iPhone, everything works perfectly but on some devices, this error cause crashes. Could you help me please ?
Thanks.
Check all of your WKWebView that is are loading images.
If you long press on Webview it shows an option to save photos in app.
Fix for the crash:
webView?.allowsLinkPreview = false

Abnormal main.m crash

In my iOS app, I keep getting crash reports like this one.
0 libsystem_kernel.dylib 0x000000018d805014 __pthread_kill + 4
1 libsystem_c.dylib 0x000000018d7799c4 abort + 136
2 libc++abi.dylib 0x000000018d2451b0 abort_message + 128
3 libc++abi.dylib 0x000000018d25ec04 default_terminate_handler() + 300
4 libobjc.A.dylib 0x000000018d26c820 objc_terminate() + 120
5 libc++abi.dylib 0x000000018d25b5d4 std::__terminate() + 12
6 libc++abi.dylib 0x000000018d25b640 std::terminate() + 56
7 libdispatch.dylib 0x000000018d6c29b4 _dispatch_client_callout + 32
8 libdispatch.dylib 0x000000018d6c75e8 _dispatch_main_queue_callback_4CF + 992
9 CoreFoundation 0x000000018e7b90c0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10 CoreFoundation 0x000000018e7b6cdc __CFRunLoopRun + 1568
11 CoreFoundation 0x000000018e6e6d94 CFRunLoopRunSpecific + 420
12 GraphicsServices 0x0000000190150074 GSEventRunModal + 96
13 UIKit 0x000000019499f44c UIApplicationMain + 204
! 14 MyAppNameHere 0x000000010007b090 main (main.m:33)
15 libdyld.dylib 0x000000018d6f559c start + 0
The strange thing is that none of this exists within my code except for the main.m. All other threads in my application don't have anything related to either. This crash appears to only happen for a fraction of a percent of my users, so I am not sure where to even start looking.
The question as it is formulated right now is not answerable, because it is missing necessary information. See e.g. this tutorial for an explanation of how to obtain a real backtrace and how to obtain a "crash reason". Without following the recommended steps for debugging crashes every crash of an iOS-app looks exactly the same as the crash you just provided.
In order to get a real/useful backtrace, you need to set an exception breakpoint in Xcode.

GSRegisterPurpleNamedPerPIDPort crash

Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1be21acc __pthread_kill + 8
1libsystem_pthread.dylib 0x1beda086 pthread_kill + 62
2 libsystem_c.dylib 0x1bdb695a abort + 108
3 GraphicsServices 0x1dd0b83a GSRegisterPurpleNamedPerPIDPort + 0
4 GraphicsServices 0x1dd0aad8 _GSEventInitializeApp + 106
5 UIKit 0x21af68e8 _UIApplicationMainPreparations + 832
6 UIKit 0x218e2de2 UIApplicationMain + 102
7 LanSynergism 0x000d160e main (main.m:14)
8 libdyld.dylib 0x1bd4e4ea start
crash why when the app kill and begin
I had this happen to me. The cause for me was the Xcode debugger was still attached to the app on an exception breakpoint. So when I tried to relaunch the app it would close instantly with a stacktrace:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001adc810cc __pthread_kill + 8
1 libsystem_c.dylib 0x00000001adbda14c abort + 144
2 GraphicsServices 0x00000001b02b99e8 GSRegisterPurpleNamedPerPIDPort + 0
3 GraphicsServices 0x00000001b02b8b24 _GSEventInitializeApp + 132
4 UIKitCore 0x00000001db515b70 _UIApplicationMainPreparations + 960
5 UIKitCore 0x00000001db515724 UIApplicationMain + 164
6 MyWorldClock 0x000000010043c188 main + 688520 (AppDelegate.swift:20)
7 libdyld.dylib 0x00000001adb34fd8 start + 4
This looks to be the same as posted above.
The steps I was taking was I had Xcode debugger attached with exception breakpoints on, I changed the iOS device language which sent kill signal to all the apps, since the debugger was attached it fired the breakpoint. When trying to relaunch the app with debugger paused on the SIGABRT exception the app would open and close instantly on iOS device.
Hope this helps someone!

Cocos2D v2.1 and arm64 crash on iPad Air despite no compiler warnings

I'm posting here in hope for advice from more experienced programmers (in general & with Cocos2D specifically).
I have an old-ish project that is using Cocos2D v2.1 in a couple of places, otherwise it's standard UIKit. I updated it to be compliant with arm64, or so I thought, and managed to remove any compiler warnings, and run the app successfully on the simulator. However, I just got a bug report form an iPad Air user that the Cocos2d portion of the app is crashing.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001995101d0 0x1994f8000 + 98768
1 0x000000010014e820 -[CCTimer update:] + 152
2 0x0000000100152140 -[CCScheduler update:] + 420
3 0x000000010016ab30 -[CCDirectorIOS drawScene] + 172
Like I say, there are no compiler warnings and it all works on the simulator, so I'm kinda stuck as to how to fix it. I know that the usual two options would be to
1. remove arm64
2. upgrade to Cocos2D v3.0
However, I use Cocos2D only for a tiny portion of the app, so I was hoping that perhaps I am missing a simple fix. I'm pretty inexperienced with Cocos2D and debugging in general, so I'm hoping for some advice if this is a lost cause and I should better spend my time on one of the other 2 options, or perhaps there is something simple that I can tweak that I am missing right now. I did browse through the CCTimer update: methods, and the only thing that stood out were a few floats in the code, that I know can be problematic between 32/64 bit, but without a compiler warning I am at a loss.
UPDATE
So it gets mysteriouser and mysteriouser. I bought a brand new iPad Air to test this locally instead of on the simulator, and... it works. No crashes. Does the user perhaps simply have a defective device? I noticed that the Exception is thrown at KERN_INVALID_ADDRESS at 0x0000000000000010 which looks somewhat odd. Most of similar crash reports I've seen online have entirely different addresses that look much more random.
UPDATE 2
More mysteries. While the local version works on the device (run via XCode), the actually downloaded app from the AppStore does crash! I was able to capture some more info about it from the Device Logs:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000196c041d0 objc_msgSend + 16
1 0x00000001001da820 -[CCTimer update:] + 152
2 0x00000001001de140 -[CCScheduler update:] + 420
3 0x00000001001f6b30 -[CCDirectorIOS drawScene] + 172
4 QuartzCore 0x000000018cf40cb8 CA::Display::DisplayLinkItem::dispatch() + 32
5 QuartzCore 0x000000018cf40ac4 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 296
6 IOKit 0x000000018b23be70 IODispatchCalloutFromCFMessage + 360
7 CoreFoundation 0x000000018a2ec8dc __CFMachPortPerform + 188
8 CoreFoundation 0x000000018a2fae8c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
9 CoreFoundation 0x000000018a2fadec __CFRunLoopDoSource1 + 440
10 CoreFoundation 0x000000018a2f9010 __CFRunLoopRun + 1616
11 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
12 GraphicsServices 0x000000018fec9c08 GSEventRunModal + 164
13 UIKit 0x000000018d36afd8 UIApplicationMain + 1152
14 0x00000001000f4994 main (main.m:16)
15 libdyld.dylib 0x00000001971e7a9c start + 0
Thread 1:
0 libsystem_kernel.dylib 0x00000001972c9aa8 kevent64 + 8
1 libdispatch.dylib 0x00000001971cd998 _dispatch_mgr_thread + 48
Thread 2:
0 libsystem_kernel.dylib 0x00000001972c9ca0 mach_msg_trap + 8
1 CoreFoundation 0x000000018a2fab70 __CFRunLoopServiceMachPort + 180
2 CoreFoundation 0x000000018a2f8d00 __CFRunLoopRun + 832
3 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
4 AudioToolbox 0x0000000189aedabc GenericRunLoopThread::Entry(void*) + 156
5 AudioToolbox 0x0000000189ade278 CAPThread::Entry(CAPThread*) + 136
6 libsystem_pthread.dylib 0x0000000197363e18 _pthread_body + 164
7 libsystem_pthread.dylib 0x0000000197363d70 _pthread_start + 136
8 libsystem_pthread.dylib 0x0000000197361550 thread_start + 0
Thread 3:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Thread 4:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Baffled.
Definitely remove arm64 from your project build settings (architecture, valid architectures) because cocos2d-iphone prior to v3 is not compatible with 64-bit builds even if you do not get compiler warnings/errors. There are some nasty potential issues hidden away.
If you do not receive compiler warnings I think it's likely that the 32/64 bit compatibility issues warnings are simply not enabled in your project/target (specifically the cocos2d-iphone target if it's in a separate target). In stock v2.1 of cocos2d there should actually be plenty of such warnings, though it may depend on your iOS Deployment target (for a test try setting it to iOS 7.1 which will give you the most warnings, including many "deprecation" warnings).
You can also perform an Analyze build to point out potential issues (and some false alerts, too).

Resources