Flutter iOS Release Crash: Firebase FireStore Util - ios

I have been trying to debug this issue for almost 8 days now. Tried everything I can find on the internet / stack overflow / github and still on the same problem. I have done all the basic troubleshooting (cleaning, deintegrating pods, etc.) and even adding the GoogleService-info.plist through Xcode.
There is no problem on debug modes and on android release mode. It only occurs on iOS release mode on test flight and on app store connect but works on the emulator / debug mode. Below is the stack trace:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Application Specific Information:
abort() called
Last Exception Backtrace:
0 CoreFoundation 0x1c8b25e88 __exceptionPreprocess + 164
1 libobjc.A.dylib 0x1c1e538d8 objc_exception_throw + 60
2 FirebaseFirestore 0x102f1bc08 firebase::firestore::util::ObjcThrowHandler(firebase::firestore::util::ExceptionType, char const*, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 112
3 FirebaseFirestore 0x102f1b78c firebase::firestore::util::Throw(firebase::firestore::util::ExceptionType, char const*, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 20
4 FirebaseFirestore 0x102f2284c void firebase::firestore::util::ThrowInvalidArgument<>(char const*) + 56
5 FirebaseFirestore 0x102f4d3b4 -[FIRFirestore documentWithPath:] + 308
6 Runner 0x1023730c4 -[FLTFirebaseFirestoreReader readValueOfType:] + 2339012 (FLTFirebaseFirestoreReader.m:38)
7 Flutter 0x10576d9c0 0x1051f4000 + 5740992
8 Runner 0x102373040 -[FLTFirebaseFirestoreReader readValueOfType:] + 2338880 (FLTFirebaseFirestoreReader.m:79)
9 Flutter 0x10576ee54 0x1051f4000 + 5746260
10 Flutter 0x10576bc8c 0x1051f4000 + 5733516
11 Flutter 0x105237de4 0x1051f4000 + 277988
12 libdispatch.dylib 0x1d00f44b4 _dispatch_call_block_and_release + 32
13 libdispatch.dylib 0x1d00f5fdc _dispatch_client_callout + 20
14 libdispatch.dylib 0x1d01047f4 _dispatch_main_queue_drain + 928
15 libdispatch.dylib 0x1d0104444 _dispatch_main_queue_callback_4CF + 44
16 CoreFoundation 0x1c8bb66f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
17 CoreFoundation 0x1c8b98058 __CFRunLoopRun + 2036
18 CoreFoundation 0x1c8b9ced4 CFRunLoopRunSpecific + 612
19 GraphicsServices 0x201e9a368 GSEventRunModal + 164
20 UIKitCore 0x1cb07b3d0 -[UIApplication _run] + 888
21 UIKitCore 0x1cb07b034 UIApplicationMain + 340
22 Runner 0x10213dbe0 main + 23520 (AppDelegate.swift:5)
23 dyld 0x1e7204960 start + 2528
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x205720200 __pthread_kill + 8
1 libsystem_pthread.dylib 0x215b821ac pthread_kill + 268
2 libsystem_c.dylib 0x1d01b13e4 __abort + 128
3 libsystem_c.dylib 0x1d0159c98 abort + 192
4 libc++abi.dylib 0x215ac2b8c abort_message + 132
5 libc++abi.dylib 0x215ab2a80 demangling_terminate_handler() + 336
6 libobjc.A.dylib 0x1c1e59d3c _objc_terminate() + 144
7 libc++abi.dylib 0x215ac1f28 std::__terminate(void (*)()) + 20
8 libc++abi.dylib 0x215ac1ec4 std::terminate() + 56
9 libdispatch.dylib 0x1d00f5ff0 _dispatch_client_callout + 40
10 libdispatch.dylib 0x1d01047f4 _dispatch_main_queue_drain + 928
11 libdispatch.dylib 0x1d0104444 _dispatch_main_queue_callback_4CF + 44
12 CoreFoundation 0x1c8bb66f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
13 CoreFoundation 0x1c8b98058 __CFRunLoopRun + 2036
14 CoreFoundation 0x1c8b9ced4 CFRunLoopRunSpecific + 612
15 GraphicsServices 0x201e9a368 GSEventRunModal + 164
16 UIKitCore 0x1cb07b3d0 -[UIApplication _run] + 888
17 UIKitCore 0x1cb07b034 UIApplicationMain + 340
18 Runner 0x10213dbe0 main + 23520 (AppDelegate.swift:5)
19 dyld 0x1e7204960 start + 2528
Below will also be the code that is affected. I tried to pinpoint the problem and when I comment docRef.get() method, it doesn't crash on test flight anymore:
Future<List<dbResults>> results({
required String collectionKey,
required String documentKey,
required int count,
}) async {
FirebaseFirestore firestore = FirebaseFirestore.instance;
DocumentReference docRef =
firestore.collection(collectionKey).doc(documentKey);
List<dbResults> databaseResults = [];
await docRef.get().then((datasnapshot) {
if (datasnapshot.exists) {
try {
datbaseResults = datasnapshot.get('results');
// Additional Logic Here which won't even matter as
// it throws on docRef.get() itself (tried and tested)
}
} catch (_) {
if (kDebugMode) {
print("Error fetching game database results.");
}
}
}
});
return databaseResults;
}
Flutter: 3.3.9
Pubspec:
Cloud Firestore : 4.1.0
Firebase Core: 2.3.0
Any help would be appreciated!
I have exhausted the resources online and submitted +30 builds just to address the issue.

I managed to fix it by adding a conditional check on the parameters being passed to the function if they are not empty before performing the query.
Just a bit weird because the above function isn't even being called on app start and it seems that Swift is trying to call the function on app start and crash but on Android Release and both debug modes, everything is normal.
For all the other devs out there that is on the same boat, please learn from my mistake
Thank you Ali Nabel for helping too!

Related

-[EAGLContext presentRenderbuffer:] crash in iOS 14

We encountered an OpenGL related crash on ios14. It has nothing to do with the application background. The vast majority of crashes occurred on IOS 14 low-end devices, and it is not clear how to solve them.
The only possible clue is that the crash may have something to do with opening the WebView.
Monitor Type: Unix Signal
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000 at 0x00000001c7517414
Crashed Thread: 0
Pthread id: 10322737
Thread 0 Crashed:
0 libsystem_kernel.dylib __pthread_kill + 8
1 libsystem_pthread.dylib pthread_kill + 272
2 libsystem_c.dylib abort + 104
3 AppleMetalGLRenderer GLDContextRec::flushContextInternal() + 852
4 GLEngine gliPresentViewES_Exec + 188
5 OpenGLES -[EAGLContext presentRenderbuffer:] + 76
6 myapp -[EJCanvasContextWebGLScreen present] (EJCanvasContextWebGLScreen.m:142)
7 QuartzCore CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 664
8 QuartzCore display_timer_callback(__CFMachPort*, void*, long, void*) + 280
9 CoreFoundation __CFMachPortPerform + 176
10 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60
11 CoreFoundation __CFRunLoopDoSource1 + 596
12 CoreFoundation __CFRunLoopRun + 2360
13 CoreFoundation CFRunLoopRunSpecific + 600
14 GraphicsServices GSEventRunModal + 164
15 UIKitCore -[UIApplication _run] + 1072
16 UIKitCore UIApplicationMain + 168
17 myapp main (main.m:36)
18 libdyld.dylib start + 4
I'm 100% sure presentRenderBuffer works fine in iOS14.
According to the error message, it seems like a thread issue.
In my case, I use a queue to detail with all of the OpenGL things.
dispatch_sync(queue, ^{
// All of the OpenGL things
[self bindCurrentRenderBuffer];
[self presentRenderBuffer];
});
You can see my OpenGL project in Github: IRPlayer

CoreData _NSIsNSSet EXC_BAD_ACCESS KERN_INVALID_ADDRESS - crash on app launch

We are getting this crash on multiple devices but cannot figure out where it originates from. The main thread is crashing.
Stack trace:
Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x193dfd58c object_getMethodImplementation + 20
1 CoreFoundation 0x1940f6928 _NSIsNSSet + 40
2 CoreFoundation 0x193fc2c04 -[NSMutableSet unionSet:] + 112
3 CoreData 0x198abe014 -[_NSFaultingMutableSet willReadWithContents:] + 668
4 CoreData 0x198ae4280 -[_NSFaultingMutableSet count] + 32
5 CoreData 0x198be1bb4 __107-[NSManagedObjectContext(_NestedContextSupport) newValueForRelationship:forObjectWithID:withContext:error:]_block_invoke + 360
6 CoreData 0x198be2e70 internalBlockToNSManagedObjectContextPerform + 104
7 libdispatch.dylib 0x193d8b5ac _dispatch_client_callout + 20
8 libdispatch.dylib 0x193d9843c _dispatch_async_and_wait_invoke + 96
9 libdispatch.dylib 0x193d8b5ac _dispatch_client_callout + 20
10 libdispatch.dylib 0x193d977d4 _dispatch_main_queue_callback_4CF + 832
11 CoreFoundation 0x1940648d4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
12 CoreFoundation 0x19405f58c __CFRunLoopRun + 1692
13 CoreFoundation 0x19405ebc8 CFRunLoopRunSpecific + 480
14 GraphicsServices 0x19e4475cc GSEventRunModal + 164
15 UIKitCore 0x198211744 UIApplicationMain + 1936
16 My App 0x100b37324 main + 16 (main.m:16)
17 libdyld.dylib 0x193edb384 start + 4
At the same time, a background thread operating in a PrivateQueue ManagedObjectContext is busy accessing a ManagedObject via awakeFromFetch, stack trace of this thread:
NSManagedObjectContext 0x28066c700
0 libsystem_kernel.dylib 0x1b09617e4 __ulock_wait + 8
1 libdispatch.dylib 0x1b081bf48 _dlock_wait + 56
2 libdispatch.dylib 0x1b081bcf4 _dispatch_thread_event_wait_slow + 56
3 libdispatch.dylib 0x1b0828618 __DISPATCH_WAIT_FOR_QUEUE__ + 336
4 libdispatch.dylib 0x1b0828204 _dispatch_sync_f_slow + 144
5 CoreData 0x1b56686cc _perform + 200
6 CoreData 0x1b558e2c4 -[NSManagedObjectContext(_NestedContextSupport) newValueForRelationship:forObjectWithID:withContext:error:] + 156
7 CoreData 0x1b555033c -[NSFaultHandler retainedFulfillAggregateFaultForObject:andRelationship:withContext:] + 428
8 CoreData 0x1b554df10 -[_NSFaultingMutableSet willReadWithContents:] + 408
9 CoreData 0x1b55ea5bc -[_NSFaultingMutableSet allObjects] + 32
10 My App 0x1044fdc3c PSUser.isAdmin.getter + 286 (PSUser.swift:286)
11 My App 0x1044fdb04 #objc PSUser.isAdmin.getter + 4309900036 (<compiler-generated>:4309900036)
12 My App 0x1044fc694 PSUser.initCurrentTeam() + 212 (PSUser.swift:212)
13 My App 0x1044fcbc0 #objc PSUser.initCurrentTeam() + 4309896128 (<compiler-generated>:4309896128)
14 My App 0x1044fc658 #objc PSUser.awakeFromFetch() + 4309894744 (<compiler-generated>:4309894744)
15 CoreData 0x1b56520e4 _PFFaultHandlerFulfillFault + 3168
16 CoreData 0x1b5650ab0 _PFFaultHandlerLookupRow + 908
17 CoreData 0x1b56527fc _PF_FulfillDeferredFault + 260
18 CoreData 0x1b5666a2c _pvfk_header + 120
19 CoreData 0x1b5663218 _sharedIMPL_pvfk_core + 32
20 My App 0x10438918c +[PSAppSettings isAutoPilotAllowed:] + 97 (PSAppSettings.m:97)
21 My App 0x1043fbb9c LocationTracker.updateTrackingState(user:) + 1120 (LocationTracker.swift:1120)
22 My App 0x104413b4c partial apply for closure #1 in LocationTracker.store(filteredLocations:) + 1275 (LocationTracker.swift:1275)
23 My App 0x1043bae3c thunk for #escaping #callee_guaranteed () -> () + 4308577852 (<compiler-generated>:4308577852)
24 CoreData 0x1b566b650 developerSubmittedBlockToNSManagedObjectContextPerform + 164
25 libdispatch.dylib 0x1b081b5ac _dispatch_client_callout + 20
26 libdispatch.dylib 0x1b0821a64 _dispatch_lane_serial_drain + 568
27 libdispatch.dylib 0x1b0822498 _dispatch_lane_invoke + 400
28 libdispatch.dylib 0x1b082ba5c _dispatch_workloop_worker_thread + 584
29 libsystem_pthread.dylib 0x1b0881718 _pthread_wqthread + 276
30 libsystem_pthread.dylib 0x1b08879c8 start_wqthread + 8
I am not certain if the two stacks are related, or if the background thread is dispatching anything to the main thread (why should it?), but the call newValueForRelationship:forObjectWithID:withContext:error does appear in both stack traces.
The method for awakeFromFetch is initializing a calculated object property currentTeam via the initCurrentTeam() method. This method accesses the teams relationship on that object. Here is the relevant code:
#objc extension PSUser {
override open func awakeFromFetch() {
super.awakeFromFetch()
initCurrentTeam()
}
/**
This method sets the currentTeam by picking
the appropriate team from the `teams` set.
*/
func initCurrentTeam() {
if (isAdmin || isManager), !isEmployee,
var teams = teams?.allObjects as? [PSTeam],
currentTeam == nil {
...
currentTeam = teams.first
}
}
...
}
Enabled com.apple.CoreData.ConcurrencyDebug in Xcode Scheme but Xcode console does not complain. I have not been able to reproduce this issue while debugging in Xcode. The issue is only reported via Crashlytics in production environment.
Any ideas what might be causing this?

How can I interpret this stacktrace

I am seeing some crashes that I cannot properly read.
Background: The app has a react native part. Below the regular react native objc code with some additional modules. The there is lot of custom objc and swift code. And on the very bottom we have a c/c++ engine doing their voodoo.
Note: Those stack traces are taken from Firebase / Crashlytics. Are these logs looking like DSYM files are missing? Or am I just not able to read them?
First stacktrace
Crashed: com.apple.main-thread
0 Objc/C++Part 0x104052a6c Engine::setTask(Task const*) + 408
1 SwiftPart 0x102dc14a8 __swift_memcpy2_1 + 3268
2 SwiftPart 0x102d89c2c globalinit_33_D059BB15480DF7E417659EA3E0158837_func83 + 2880
3 SwiftPart 0x102dc6a28 globalinit_33_164233930FF8443B67F99609B74287FF_func109 + 496
4 SwiftPart 0x102dc2ff4 globalinit_33_F9D0611596767A886B653DD36AB555FE_func108 + 2208
5 Foundation 0x196131050 __NSFireTimer + 64
6 CoreFoundation 0x195cc5e00 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
7 CoreFoundation 0x195cc5b3c __CFRunLoopDoTimer + 880
8 CoreFoundation 0x195cc520c __CFRunLoopDoTimers + 276
9 CoreFoundation 0x195cc0348 __CFRunLoopRun + 1920
10 CoreFoundation 0x195cbf8a0 CFRunLoopRunSpecific + 464
11 GraphicsServices 0x19fc17328 GSEventRunModal + 104
12 UIKitCore 0x199db0740 UIApplicationMain + 1936
13 MainApplication 0x1023390e4 main + 16 (main.m:16)
14 libdyld.dylib 0x195b4a360 start + 4
What does the line 2 SwiftPart 0x102d89c2c globalinit_33_D059BB15480DF7E417659EA3E0158837_func83 + 2880 mean for example? How can I find out what line Engine::setTask(Task const*) + 408 exactly means?
Second stacktrace
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x1aba7b440 swift_isUniquelyReferenced_nonNull_native + 34
1 MainApplication 0x100bb6f60 thunk for #escaping #callee_guaranteed () -> () + 4309315424 (<compiler-generated>:4309315424)
2 libdispatch.dylib 0x19e18b7dc _dispatch_block_async_invoke2 + 104
3 libdispatch.dylib 0x19e1d9184 _dispatch_client_callout + 16
4 libdispatch.dylib 0x19e18b190 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
5 CoreFoundation 0x19e48a5e4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
6 CoreFoundation 0x19e4855d8 __CFRunLoopRun + 2004
7 CoreFoundation 0x19e484adc CFRunLoopRunSpecific + 464
8 GraphicsServices 0x1a840a328 GSEventRunModal + 104
9 UIKitCore 0x1a257fae0 UIApplicationMain + 1936
10 MainApplication 0x100b310e4 main + 16 (main.m:16)
11 libdyld.dylib 0x19e30e360 start + 4
Same here. How to read this?

Interpreting a TestFlight crash report

I just made some updates to my app, and have been seeing some new crash reports in TestFlight that I can't find much information on online. Can anyone help me interpret what's going on here? It's happening in different places throughout my app, so I don't think it's related to one specific function...
0 MyApp 0x000832b6 testflight_backtrace + 238
1 MyApp 0x00083fa0 TFSignalHandler + 264
2 libsystem_c.dylib 0x35e2be92 _sigtramp + 42
3 libdispatch.dylib 0x3a3c611e _dispatch_call_block_and_release + 10
4 libdispatch.dylib 0x3a3c611e _dispatch_call_block_and_release + 10
5 libdispatch.dylib 0x3a3c54b6 _dispatch_client_callout + 22
6 libdispatch.dylib 0x3a3ca1bc _dispatch_main_queue_callback_4CF$VARIANT$mp + 224
7 CoreFoundation 0x38739f3a __CFRunLoopRun + 1290
8 CoreFoundation 0x386acebc CFRunLoopRunSpecific + 356
9 CoreFoundation 0x386acd48 CFRunLoopRunInMode + 104
10 GraphicsServices 0x36c5d2ea GSEventRunModal + 74
11 UIKit 0x39e7a2f8 UIApplicationMain + 1120
12 MyApp 0x0003078a main (main.m:16)
13 MyApp 0x0003073f start + 39

App crashes in the thread named com.apple.CFURLCACHE_work_queue

My app crashed in the thread named com.apple.CFURLCACHE_work_queue and the crash logs doesn't seem to provide any clues for me to find a bug or mistake =(
Thread 10 name: Dispatch queue: com.apple.CFURLCACHE_work_queue
Thread 10 Crashed:
0 libsystem_kernel.dylib 0x32e93350 __pthread_kill + 8
1 libsystem_c.dylib 0x3b04011e pthread_kill + 54
2 libsystem_c.dylib 0x3b07c96e abort + 90
3 libc++abi.dylib 0x343ebd4a abort_message + 70
4 libc++abi.dylib 0x343e8ff4 default_terminate() + 20
5 libobjc.A.dylib 0x3559fa74 _objc_terminate() + 144
6 libc++abi.dylib 0x343e9078 safe_handler_caller(void (*)()) + 76
7 libc++abi.dylib 0x343e9110 std::terminate() + 16
8 libc++abi.dylib 0x343ea50e __cxa_throw + 118
9 libobjc.A.dylib 0x3559f9ba objc_exception_throw + 90
10 Foundation 0x34d42b60 _NSOutOfMemoryErrorHandler + 56
11 CoreFoundation 0x3725130a __CFDataHandleOutOfMemory + 90
12 CoreFoundation 0x37251458 __CFDataGrow + 288
13 CoreFoundation 0x371d6134 CFDataReplaceBytes + 360
14 CoreFoundation 0x371e3a9a CFDataAppendBytes + 82
15 CFNetwork 0x33150438 CopyAllDataFromDataArray(__CFArray const*) + 104
16 CFNetwork 0x331509ae __CFURLCache::ExecuteSQLInsert(_CFCachedURLResponse const*, __CFString const*, _CFURLRequest const*) + 370
17 CFNetwork 0x3314ec62 __CFURLCache::AddCachedResponseForRequest(__CFURLCacheNode*, _CFCachedURLResponse const*, _CFURLRequest const*) + 58
18 CFNetwork 0x3314eab8 __CFURLCache::ProcessCacheTasks0(bool) + 140
19 CFNetwork 0x3314ea1c __CFURLCache::ProcessCacheTasks(bool) + 32
20 CFNetwork 0x3314e8f0 __CFURLCache::_CFURLCacheTimerCallback0() + 280
21 CFNetwork 0x3314e7c8 __CFURLCache::_CFURLCacheTimerCallback(void*) + 28
22 libdispatch.dylib 0x35f86134 _dispatch_source_invoke$VARIANT$mp + 248
23 libdispatch.dylib 0x35f83e8e _dispatch_queue_drain$VARIANT$mp + 78
24 libdispatch.dylib 0x35f83dbc _dispatch_queue_invoke$VARIANT$mp + 36
25 libdispatch.dylib 0x35f8491a _dispatch_root_queue_drain + 182
26 libdispatch.dylib 0x35f84abc _dispatch_worker_thread2 + 80
27 libsystem_c.dylib 0x3b017a0e _pthread_wqthread + 358
28 libsystem_c.dylib 0x3b0178a0 start_wqthread + 4
any idea or clue of why this happens?
I guess it has something to do with NSURLCache, but I don't manipulate or even create that object in my app.
I'm using Xcode 4.5 GM - I know it's not publicly released yet - and AFNetworking 1.0RC3 for network communication and downloading image data
From the look of things in numbers 10 and 11, it ran out of memory and threw an exception, maybe as part of some kind of assertion.
You will probably find exception information in the console log for the device. If you can connect your device to your Mac, you can access this data in Xcode. Devices don't keep much console data, so it is best to get the log very soon after encountering the error.

Resources