I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

@vinitam I'm sorry you encountered the issue. Could you please also share the supplementary crash info like an exception, crash reason, etc. if available?

One of potential crash reasons I can see so far is passing NULL as a dispatch_queue to dispatch_async here due to the unchecked weakSelf variable. We will provide a fix for this potential issue to be included into the next releases. As far as I can see, this part may lead to the crash only when Firebase application is deleted by the app. Do you know if your app calls something like FirebaseApp.app(). deleteApp {...} ?

We are calling deleteApp within our app which was called previously as well.

Attaching the exception for details:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000028
VM Region Info: 0x28 is not in any region.  Bytes before following region: 4334272472
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                 000000010257c000-0000000102580000 [   16K] r-x/r-x SM=COW  ....app/*******]

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread:  0

Thread 0 name:
Thread 0 Crashed:
0   *******                       	0x0000000104afdd74 __65-[RCNConfigFetch refreshInstallationsTokenWithCompletionHandler:]_block_invoke_2 + 84 (RCNFetch.m:246)
1   *******                       	0x0000000104a81af8 __49-[FIRInstallations installationIDWithCompletion:]_block_invoke + 68 (FIRInstallations.m:181)
2   FBLPromises                   	0x0000000105c739f8 __56-[FBLPromise chainOnQueue:chainedFulfill:chainedReject:]_block_invoke.48 + 52 (FBLPromise.m:273)
3   libdispatch.dylib             	0x00000001862fea54 _dispatch_call_block_and_release + 24 (init.c:994)
4   libdispatch.dylib             	0x00000001862fea14 _dispatch_client_callout + 16 (object.m:502)
5   libdispatch.dylib             	0x000000018630b4d8 _dispatch_main_queue_callback_4CF$VARIANT$mp + 568 (inline_internal.h:2486)
6   CoreFoundation                	0x0000000186927344 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 (CFRunLoop.c:1815)
7   CoreFoundation                	0x0000000186924f20 __CFRunLoopRun + 2012 (CFRunLoop.c:3111)
8   CoreFoundation                	0x0000000186844c58 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3245)
9   GraphicsServices              	0x00000001886f0f84 GSEventRunModal + 100 (GSEvent.c:2245)
10  UIKit                         	0x000000018ff9d5c4 UIApplicationMain + 236 (UIApplication.m:3956)
12  libdyld.dylib                 	0x000000018636456c start + 4

@vinitam Thank you for the quick response. The information you provided proves that the reason I described above is most likely behind the crash.

As a temporary workaround while waiting for the fix to be released you may try to avoid deleteApp if possible.

A bit a side question - I wonder why deleteApp is needed in you app?

We are dynamically setting firebase config. So every time we set the new config we call deleteApp.

As suggested we will remove deleteApp till this is fixed. Also wanted to understand if there will be any side effect in our scenario in case we remove deleteApp.

@vinitam In general Firebase has a very limited support for dynamic configuration for now, e.g. the default Firebase app should always be configured at the app start for Analytics to work correctly. Could you please provide more details on the way you dynamically configure Firebase so we can better under if your use case is supported or you may need to make any adjustments?

Thanks for the response @maksymmalyhin.

Just to give you some idea, we are setting firebase with default options at the start of the app. We then make an API call to fetch dynamic config (api key, db url) from the backend and then use the function deleteApp and reconfigure firebase. In case, I do not use the deleteApp function I get an error saying Terminating app due to uncaught exception 'com.firebase.core', reason: 'Default app has already been configured.

@vinitam Your use case looks reasonable and supported. Calling deleteApp is required to reconfigure an app, so you were doing it correctly. Another possible option for you to avoid deleting and re-configuring the default app could be configuring a second firebase app with the config received from server. If you decide to go with multi apps please note that not all products support secondary apps so such products will keep using the default one.

The PR #6133 that should fix the crash was merged. The fix should be available in the next Firebase release. If you have a chance to test it, you may try to use remote config version from master.

Feel free to reopen the issue with more details if you still experience the crash. Thanks.

@maksymmalyhin I believe I might be having the same sort of problem?

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000028
VM Region Info: 0x28 is not in any region.  Bytes before following region: 4342579160
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                 0000000102d68000-00000001033e4000 [ 6640K] r-x/r-x SM=COW  ....app/*********

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [1074]
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   *********                      	0x0000000102f044b8 __65-[RCNConfigFetch refreshInstallationsTokenWithCompletionHandler:]_block_invoke_2 + 1688760 (RCNFetch.m:244)
1   *********                      	0x0000000102eb92fc __49-[FIRInstallations installationIDWithCompletion:]_block_invoke + 1381116 (FIRInstallations.m:176)
2   *********                      	0x0000000102f3b8e8 __56-[FBLPromise chainOnQueue:chainedFulfill:chainedReject:]_block_invoke.48 + 1915112 (FBLPromise.m:273)
3   libdispatch.dylib             	0x0000000196652134 _dispatch_call_block_and_release + 32
4   libdispatch.dylib             	0x00000001966535ac _dispatch_client_callout + 20
5   libdispatch.dylib             	0x000000019665f85c _dispatch_main_queue_callback_4CF + 968
6   CoreFoundation                	0x000000019692c8d4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
7   CoreFoundation                	0x000000019692758c __CFRunLoopRun + 1692
8   CoreFoundation                	0x0000000196926bc8 CFRunLoopRunSpecific + 480
9   GraphicsServices              	0x00000001a0d085cc GSEventRunModal + 164
10  UIKitCore                     	0x000000019aad9744 UIApplicationMain + 1936
11  *********                      	0x0000000102d6f3d8 main + 29656 (main.m:16)
12  libdyld.dylib                 	0x00000001967a3384 start + 4

I'm trying to use the master branch like you suggested like this:

  pod 'Firebase/Core'
  pod 'Firebase/Messaging'
  pod 'Firebase/RemoteConfig', :git => 'https://github.com/firebase/firebase-ios-sdk.git'

But I seem to run into this and it might be because of my use of react-native-firebase v5:

[!] There are multiple dependencies with different sources for `Firebase` in `Podfile`:

- Firebase/Core
- Firebase/Messaging
- Firebase/RemoteConfig (from `https://github.com/firebase/firebase-ios-sdk.git`)

@Pashtunzoy you can check the version of FirebaseRemoteConfig that was installed by looking at the Podfile.lock.

@morganchen12 It's FirebaseRemoteConfig (1.3.0)

The latest public (non-master) version is 4.8.0. Something in your Podfile (possibly react?) is causing the Remote Config dependency to be very out-of-date.