🔥 [🐛] RNFBConfigModule getConstantsForApp Crash on iOS

[TaylorDale]

Issue

This line has always caused a small subset of crashes for me in my apps but it's been gaining momentum as of late. Across all versions of iOS and devices.

Crashed: com.apple.root.utility-qos
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020

Occurs in RNFBConfigModule.m - Line 325
-[RNFBConfigModule getConstantsForApp:] + 325

react-native-firebase/packages/remote-config/ios/RNFBConfig/RNFBConfigModule.m

Line 325 in 605a0df

[RCTConvert double:@([remoteConfig configSettings].minimumFetchInterval)];

This is how I'm using this function call in my hooks:

/// useFirebaseConfigString.ts
import remoteConfig from '@react-native-firebase/remote-config';
import { useEffect, useState } from 'react';

export default (key: string): string | undefined => {
  const [value, setValue] = useState<string | undefined>(remoteConfig().getString(key));

  useEffect(() => {
    remoteConfig()
      .ensureInitialized()
      .then(() => {
        setValue(remoteConfig().getString(key));
      });
  }, [key]);

  return value;
};

package.json:

"@react-native-firebase/remote-config": "^18.5.0",
"react": "18.2.0",
"react-native": "0.71.13",

• Platform that you're experiencing the issue on:
  - [x] iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both

[mikehardy]

Especially with a crash bug the first thing I need you to do is to make sure you are on the latest firebase-ios-sdk which is achieved by getting this fully up to date:

"@react-native-firebase/remote-config": "^18.5.0",

I don't imagine that will fix the crash but it will make sure that any crash trace line numbers don't move around and/or that firebase-ios-sdk hasn't fixed something

I won't treat that as a block though - you've included enough info (thank you!) that I think I can start investigating a bit

[mikehardy]

Actually, if you could share the whole stack trace (looks like some frames are squished and there may be more in firebase-ios-sdk code?) that would help

[TaylorDale]

No worries! I've updated all the SDKs to latest versions and will release and confirm it still occurs (I have not been able to replicate it personally yet).

Did have a little compare across the code of the offending file and doesn't look like there has been changes between each version.

Here are the collapsed elements:

[mikehardy]

Stack trace is very interesting...inability to reproduce in combo with the stack makes it sound like a race condition, is it in the OS code or the firebase-ios-sdk code

https://github.com/firebase/firebase-ios-sdk/issues?q=is%3Aissue+EXC_BAD_ACCESS+RCNConfigFetch indicates that there are no active issues about this at the moment upstream in firebase-ios-sdk (though it appears to be a reasonable search as it's not an uncommon type of exception via closed issue count)

@paulb777 - apologies for tagging you in here, my only intention in doing so is for a sort of "how to handle this efficiently" triage. react-native-firebase repos are traditionally a burden and this is hard to reproduce as it is. Doesn't appear to have open issues but really does look like a native crash somewhere in the stack layers of iOS layers or firebase-ios-sdk 🤔

crashing versions here included firebase-ios-sdk 10.15.0 so it is a bit dated https://github.com/invertase/react-native-firebase/blob/main/CHANGELOG.md#1850-2023-09-22 - however the changelog for remote-config doesn't appear to contain anything really except the Swift restructure https://github.com/firebase/firebase-ios-sdk/blob/main/FirebaseRemoteConfig/CHANGELOG.md and the commit history is pretty quiet https://github.com/firebase/firebase-ios-sdk/commits/main/FirebaseRemoteConfig

...so I think this might be a live one

[TaylorDale]

Appreciate you looking into it!

To give you a bit of idea of scope, this error has existed for a long time in the app, farthest I can look back is 90 days but I know it's significantly older than that. Version 2.0.13 uses the following (old):
"@react-native-firebase/remote-config": "^15.2.0",

2.0.14 uses the version I mentioned in initial comment. Working on releasing a 18.7.3 (all RN firebase packages) version now and will report on the results of that.

[paulb777]

@mikehardy If the issue occurred in 10.15.0 it wouldn't be related to the Swift consolidation. If there is an SDK issue here, it may have something to do with how the invalidateAndCancel API is used on NSURLSession. cc: @ncoooke3

[mikehardy]

Looks like the @ncooke3 tag did not take - one too many 'o's, so I'll re-tag - and for avoidance of doubt my goal is to collaborate + help with repro and or testing, not just dump the issue on you. Just not sure how to make a repro or add to the test cases in firebase-ios-sdk to tickle this one as we have a lot of instances counted apparently and a stack but no reliable repro even at the react-native-firebase level at the moment

[ncooke3]

I spent some time investigating from the Firebase iOS SDK's stack trace and downward (to the crashing frame). The control flow within the Firebase iOS SDK looks to run through thread safe API. I'm still unsure if the react-native-firebase code or how the OP's code is creating the conditions for the crash. I agree with Paul that it likely has to do with -[NSURLSession invalidateAndCancel] call.

https://github.com/firebase/firebase-ios-sdk/blob/5890db966963fd76cfd020d68c0067a7741bef06/FirebaseRemoteConfig/Sources/RCNConfigFetch.m#L116

The crashing frame is happening within Apple code though and it's not clear to me why. Some observations:

• The invalidateAndCancel does not have a frame in the trace. It may have just been optimized away, but it still seems interesting here.

• The CFNetServiceBrowserSearchForDomains API is not called by Firebase code. It must be a called within the implementation of Apple's -[NSURLSession invalidateAndCancel].

  Its docs mention that it's implementation can be performed async.

  In asynchronous mode, this function returns TRUE if the search was started. Otherwise, it 
  returns FALSE.
  

  So I expect that explains the dispatch_async frame.

  And the block-related frames are likely from this comment about the API's implementation:

  If registrationDomains is FALSE, this function searches for domains that can be browsed 
  for services. When a domain is found, the callback function specified when the 
  CFNetServiceBrowser was created is called and passed an instance of a CFStringRef 
  containing the domain that was found.
  

  What's particularly interesting though is that the docs say the function is thread-safe.

---

Hi @TaylorDale, you mentioned you couldn't reproduce it. Did you try reproduce in both debug and release builds? If it's feasible, reproducing in a debug build with the Thread Sanitizer enabled (docs) would help– though I understand it may be impossible to reproduce locally.

Also, if you have access to the other threads in the crash report, it may be helpful to post them as they may expose some other Firebase-related activity that could be contributing to the crash.

---

Hi @mikehardy, for the react-native-firebase code, where/when does the code run? I'm trying to draw hints on if it's reproducible only at startup or sometime else.

---

All this to say though, it seems like this could be a NSURLSession bug. I'm unsure how Firebase is creating the conditions for CFNetServiceBrowserSearchForDomains API to fail in the way it is.

[mikehardy]

@ncooke3 luckily we have a pretty thin wrapper + all in one file for this module so it's pretty easy to reason about.

First stack I see is this line

react-native-firebase/packages/remote-config/ios/RNFBConfig/RNFBConfigModule.m

Line 139 in 605a0df

resolve([self resultWithConstants:[NSNull null] firebaseApp:firebaseApp]);

that runs and then calls the results processor we sent in as a completion handler (resultWithConstants) we sent in which runs through to getConstantsForApp here

react-native-firebase/packages/remote-config/ios/RNFBConfig/RNFBConfigModule.m

Line 314 in 605a0df

responseDict[@"constants"] = [self getConstantsForApp:firebaseApp];

...heads into the next frame in the stack, where we're trying to get config settings

react-native-firebase/packages/remote-config/ios/RNFBConfig/RNFBConfigModule.m

Lines 318 to 333 in 605a0df

	- (NSDictionary *)getConstantsForApp:(FIRApp *)firebaseApp {
	FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfigWithApp:firebaseApp];
	NSDate *lastFetchTime = remoteConfig.lastFetchTime;
	NSString *lastFetchStatus =
	convertFIRRemoteConfigFetchStatusToNSString(remoteConfig.lastFetchStatus);
	double minimumFetchInterval =
	[RCTConvert double:@([remoteConfig configSettings].minimumFetchInterval)];
	double fetchTimeout = [RCTConvert double:@([remoteConfig configSettings].fetchTimeout)];
	NSMutableDictionary *values = [NSMutableDictionary new];
	NSSet *keys = [[FIRRemoteConfig remoteConfigWithApp:firebaseApp] keysWithPrefix:nil];
	for (NSString *key in keys) {
	FIRRemoteConfigValue *value =
	[[FIRRemoteConfig remoteConfigWithApp:firebaseApp] configValueForKey:key];
	values[key] = convertFIRRemoteConfigValueToNSDictionary(value);

What is a little interesting about this path is that it's coming through "ensureInitialized" which is an API that should work just fine but our documentation points people to use fetchAndActivate normally https://rnfirebase.io/remote-config/usage#fetch--activate

...that is maybe-interesting context as perhaps that code path is just different enough somehow (perhaps timing, app startup or something?) that it triggers the problem whereas the documented / general advice leads people away from the potential problem. As a counter-argument to this, all of fetch, fetchAndActivate and ensureInitialized APIs at the react-native-firebase layer appear to reduce down to this same react-native-firebase resultWithConstants method that works through the config settings. So I don't think much of this line of thought, but I thought I would advance it for consideration just in case

[TaylorDale]

Hi @ncooke3 - will review and attempt first part of your comment but I can attach a full crash report here.

Confirming that this is happening on package version 18.7.3, as well - this is from the updated version.

https://github.com/invertase/react-native-firebase/files/13721492/issue_f0f8d6c8792d0ab97a23cee549dcb86d_crash_session_be29dacc9a4149f695c1b5aa76c44a9d_DNE_0_v2_stacktrace.txt

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.