Firebase-ios-sdk: Crash in FIRLogger.m, line 141

[nikolaykasyanov]

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.4.1
• Firebase SDK version: 6.21.0
• Firebase Component: Core
• Component version: 6.21.0 (although we were getting the same issue on 6.17.0)
• Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem

I couldn't find anything suspicious in the crash reports, no jailbreak, no running out of disk space etc. Please let me know what else to look at. The only thing worth mentioning is that it happens on iOS 11 and iOS 12 only, no iOS 13 so far.
We're getting crashes in this file via Crashlytics with the following stacktrace:

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000004900
0  libsystem_c.dylib              0x1810ee38c strlen
1  CoreFoundation                 0x181718cec __CFStringAppendFormatCore
2  CoreFoundation                 0x181718cec __CFStringAppendFormatCore
3  CoreFoundation                 0x18171a740 _CFStringCreateWithFormatAndArgumentsAux2
4  GoogleUtilities                0x102b52118 (Missing)
5  idma                           0x100951b40 FIRLogBasic + 141 (FIRLogger.m:141)
6  idma                           0x100966778 FIRCLSWarningLog + 44 (FIRCLSLogger.m:44)
7  idma                           0x10095fdb4 __FIRCLSExceptionCheckHandlers_block_invoke_2 + 372 (FIRCLSException.mm:372)
8  idma                           0x1009808bc FIRCLSLookupFunctionPointer + 34 (FIRCLSUtility.m:34)
9  idma                           0x100972b98 __52-[FIRCLSReportManager crashReportingSetupCompleted:]_block_invoke + 498 (FIRCLSReportManager.m:498)
10 libdispatch.dylib              0x18104ca60 _dispatch_client_callout
11 libdispatch.dylib              0x181054e94 _dispatch_continuation_pop$VARIANT$mp
12 libdispatch.dylib              0x18105e784 _dispatch_source_invoke$VARIANT$mp
13 libdispatch.dylib              0x181059534 _dispatch_main_queue_callback_4CF$VARIANT$mp
14 CoreFoundation                 0x181703070 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
15 CoreFoundation                 0x181700bc8 __CFRunLoopRun
16 CoreFoundation                 0x181620da8 CFRunLoopRunSpecific
17 GraphicsServices               0x183606020 GSEventRunModal
18 UIKit                          0x18b640758 UIApplicationMain
19 idma                           0x100911d24 main + 24 (AppDelegate.swift:24)
20 libdyld.dylib                  0x1810b1fc0 start

Steps to reproduce:

I'm not sure what exact steps are, although according to the crash reports it usually happens upon application start.
We are only using Analytics, Crashlytics and Remote Config components so far.

Relevant Code:

// not applicable

[ryanwilson]

It looks like that this could be the culprit:

https://github.com/firebase/firebase-ios-sdk/blob/31e054a1de82ed0dc289a1b49a7cecf2a9924ae9/Crashlytics/Crashlytics/Handlers/FIRCLSException.mm#L371

When the following check fails, it returns two NULL strings which don't get formatted correctly.

https://github.com/firebase/firebase-ios-sdk/blob/b9e8c4852c78b525e004e22263a52a11f49f6c07/Crashlytics/Crashlytics/Helpers/FIRCLSUtility.m#L33-L36

Will need to double check with the Crashlytics folks to make sure this is right and what the appropriate action here is.

[samedson]

Hey thanks for reaching out @nikolaykasyanov.

• This check is to make sure Crashlytics is the only SDK to register exception handlers. iOS doesn't have good support for multiple exception handlers, so often when other SDKs also register exception handlers, Crashlytics detects it and does not start up.

• When FIRCLSLookupFunctionPointer passes NULL to the block, it comes out as a log like this:

[Firebase/Crashlytics][I-CLS000000] Warning: NSUncaughtExceptionHandler is '(null)' in '(null)'

• So I think something else is happening in this case. Crashlytics is not supposed to crash when the block gets called. I have a hunch that the call to dladdr(ptr, &info) could be turning up some garbage memory, but returning a non-zero status.

For you:

• Can you validate that none of the other SDKs you have installed register exception handlers?

[nikolaykasyanov]

@samedson thanks for your reply!

How can I check that no other SDKs install exception handlers? Any specific symbolic breakpoint I could use?

We have another SDK installed that has crash reporting but we specifically disabled the crash reporting component of it while moving to Crashlytics.

[samedson]

I'm not sure if it'll be easy to do via breakpoint for closed source SDKs. Usually SDKs will mention it in their documentation somewhere.

You're looking for SDKs that call:

set_terminate (std::set_terminate)

[google-oss-bot]

Hey @nikolaykasyanov. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[nikolaykasyanov]

@samedson I might have found a suspect: it's Kotlin/Native runtime calling std::set_terminate upon initialization. If I rearrange my code to reliably start K/N runtime _before_ Crashlytics, I do get a warning log from Crashlytics "Warning: std::get_terminate is '_ZL21KonanTerminateHandlerv' in /path/to/MyKN.framework/MyKN".

This doesn't explain what may cause dladdr to return garbage, however.

[nikolaykasyanov]

Just a thought: would it be reasonable to consider dladdr buggy pre-iOS 13 (as this issue has only been happening to iOS 11 and 12 among our userbase so far) and use some generic log message instead of the detailed one on these iOS versions?

[samedson]

@nikolaykasyanov I'd be worried about making that change as this is the first report of that line of code being an issue and Crashlytics has been installed on tons of iOS 11 and 12 devices - I have a hunch there's something specific to your setup that's resulting in this crash. To me it's extra odd that running Crashlytics before the K/N SDK results in the crash, and not the other way around as there shouldn't be anything set for set_terminate until either of those SDKs starts up.

But to resolve your issue, it looks like there may be some defines in the K/N SDK that you can use to turn off their call to set_terminate:
https://github.com/JetBrains/kotlin-native/blob/851ef95672703be9f860bd58edd29723f8c1d721/runtime/src/main/cpp/Exceptions.cpp#L294

Maybe KONAN_HAS_CXX11_EXCEPTION_FUNCTIONS?

[nikolaykasyanov]

@samedson that was a long shot indeed. Thanks for sharing the insights.

Meanwhile the crash has stopped happening for us, I'm trying to pinpoint the reason but I'm 100% sure no Firebase update is involved. This could mean that this is/was something special to our setup indeed.

[morganchen12]

Thanks for the update @nikolaykasyanov, I'll close this issue since the crash is no longer occurring but if it regresses feel free to continue commenting here and I'll reopen the issue.