Fatal Exception: NSInvalidArgumentException -[NSNull dataUsingEncoding:]: unrecognized selector sent to instance 0x21c34e538

[yeaahboy]

Description

We are receiving crash reports in Crashlytics, one of which appears to originate from Firebase. It seems unlikely that our app is directly causing this issue, as it looks like the library encounters a problem while decoding a value that turns out to be NSNull. Even if a nil value is returned from the source, we believe the library should handle it gracefully during the decoding process.

Below is the stack trace for your reference:

Reproducing the issue

No response

Firebase SDK Version

11.0.0

Xcode Version

16.1

Installation Method

CocoaPods

Firebase Product(s)

Remote Config

Targeted Platforms

iOS

Relevant Log Output

Crashed: com.google.firebase.crashlytics.ios.exception
0  FirebaseCrashlytics            0x1d004 FIRCLSProcessRecordAllThreads + 392 (FIRCLSProcess.c:392)
1  FirebaseCrashlytics            0x1d3e4 FIRCLSProcessRecordAllThreads + 423 (FIRCLSProcess.c:423)
2  FirebaseCrashlytics            0x14db0 FIRCLSHandler + 34 (FIRCLSHandler.m:34)
3  FirebaseCrashlytics            0xf9e8 __FIRCLSExceptionRecord_block_invoke + 240 (FIRCLSException.mm:240)
4  libdispatch.dylib              0x64780 _dispatch_client_callout + 16
5  libdispatch.dylib              0x46a50 _dispatch_lane_barrier_sync_invoke_and_complete + 52
6  FirebaseCrashlytics            0xe990 FIRCLSExceptionRecord + 242 (FIRCLSException.mm:242)
7  FirebaseCrashlytics            0xf4ac FIRCLSExceptionRecordNSException + 126 (FIRCLSException.mm:126)
8  FirebaseCrashlytics            0xe598 FIRCLSTerminateHandler() + 407 (FIRCLSException.mm:407)
9  libc++abi.dylib                0x13424 std::__terminate(void (*)()) + 12
10 libc++abi.dylib                0x133d4 std::terminate() + 52
11 libobjc.A.dylib                0x2adf8 objc::DenseMapBase<objc::DenseMap<objc_class*, PendingInitialize*, objc::DenseMapValueInfo<PendingInitialize*>, objc::DenseMapInfo<objc_class*>, objc::detail::DenseMapPair<objc_class*, PendingInitialize*> >, objc_class*, PendingInitialize*, objc::DenseMapValueInfo<PendingInitialize*>, objc::DenseMapInfo<objc_class*>, objc::detail::DenseMapPair<objc_class*, PendingInitialize*> >::FatalCorruptHashTables(objc::detail::DenseMapPair<objc_class*, PendingInitialize*> const*, unsigned int) const + 10
12 libdispatch.dylib              0x64794 _dispatch_client_callout + 36
13 libdispatch.dylib              0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600
14 libdispatch.dylib              0x401b0 _dispatch_lane_invoke$VARIANT$armv81 + 380
15 libdispatch.dylib              0x49f14 _dispatch_workloop_worker_thread + 608
16 libsystem_pthread.dylib        0x1bd0 _pthread_wqthread + 284
17 libsystem_pthread.dylib        0x1720 start_wqthread + 8

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[rizafran]

Thanks for reporting, @yeaahboy. Based on your stack trace, the com.google.firebase.crashlytics.ios.exception thread only captures exceptions thrown elsewhere to record the crash information. Crashlytics sometimes blames its own crash processing thread, but the crash is not actually caused by Crashlytics. With this, we'll need more information such as the full stack trace or reproducible steps to be able to help.

[yeaahboy]

Thanks for reporting, @yeaahboy. Based on your stack trace, the com.google.firebase.crashlytics.ios.exception thread only captures exceptions thrown elsewhere to record the crash information. Crashlytics sometimes blames its own crash processing thread, but the crash is not actually caused by Crashlytics. With this, we'll need more information such as the full stack trace or reproducible steps to be able to help.

Hmm, I was sure I mentioned the source of the issue in the title. Looks like not, sorry.
That's exactly what I get from Crashlytics report:
-[RCNConfigContent handleUpdateStateForConfigNamespace:withEntries:]
NSInvalidArgumentException - -[NSNull dataUsingEncoding:]: unrecognized selector sent to instance

FirebaseRemoteConfig
RCNConfigContent.m:347

It points onto RCNConfigContent class. I can see that the crash occurs due to an attempt to access NSNull during the process of encoding something into NSData. We don't have any NSNull objects or Objective-C code in our project — the only one is Firebase. Additionally, the error states: -[RCNConfigContent handleUpdateStateForConfigNamespace:withEntries:]. RCNConfigContent is a Firebase's library object, and I can see the use of dataUsingEncoding in this class.

P.S. Unfortunately the crash doesn't occur constantly. We've got only 5 cases when crash happened. But imo you are mussing NSNull checking somewhere before this line of code:
NSData *valueData = [entries[key] dataUsingEncoding:NSUTF8StringEncoding];

[paulb777]

Thanks @yeaahboy. Would you share the full stack trace including the thread with the Remote Config crash? Is there a particular Remote Config value in the console that triggers the crash?

[yeaahboy]

@paulb777 I cannot see any suspicious data in our Remote Config, probably it had some that couldn't be encoded, but now all looks fine and doesn't trigger any crashes.

Here's the stack trace.

stacktrace.txt

[paulb777]

Thanks @yeaahboy. Is your app using a custom sqlite3 implementation? Remote Config relies upon linking the system sqlite3.

[yeaahboy]

@paulb777 Nope. We are not using sqlite in our project

[paulb777]

Hmm. I'm not sure how an NSNull could get into the entries array. It would be very helpful to have reproducible example to investigate.