Firebase-ios-sdk: Watchdog timeout (8badf00d)

[icedice]

[REQUIRED] Step 2: Describe your environment

• Xcode version: 11.0
• Firebase SDK version: 6.9.0
• Firebase Component: Unknown
• Component version: 6.9.0
  
  
  
  • Using carthage
  
  

[REQUIRED] Step 3: Describe the problem

Some of our users report watchdog timeouts (0x8badf00d), so far we are unable to reproduce the issue but we have been able to get hold of a few crash logs. The logs shows that no code of ours is executed, meaning that the timeout happens before didFinishLaunchingWithOptions is getting called.
The only non-apple code executed seems to be related to GTMSessionFetcher which I believe is a firebase dependency. Which combined with some Apple tech support leads me to believe this is the right place for an answer. There seems to be a lot of calls to UserDefaults stuff. I suspect they are the cause of the timeout and that they somehow origin from the Firebase SDK.

Hopefully someone will be able to shed some light on the issue.

Crash log

See attachment

crash.txt

[google-oss-bot]

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.

[morganchen12]

Can you share your Podfile.lock?

[icedice]

Can you share your Podfile.lock?

I'm using carthage... cartfile.resolved looks like this:

binary "https://building42.github.io/Specs/Carthage/iOS/Crashlytics.json" "3.14.0"
binary "https://building42.github.io/Specs/Carthage/iOS/Fabric.json" "1.10.2"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json" "6.9.0"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json" "6.9.0"
github "Alamofire/Alamofire" "4.9.0"
github "alickbass/CodableFirebase" "0.2.1"
github "appnexus/mobile-sdk-ios" "6.0"
github "ashleymills/Reachability.swift" "v4.3.1"
github "ccgus/fmdb" "2.7.5"
github "mxcl/PromiseKit" "6.11.0"
github "onevcat/Kingfisher" "4.10.1"
github "robnadin/MMDrawerController" "e245cb0cb331aec4822c22f0f8bcb1521eb295bb"
github "scinfu/SwiftSoup" "2.2.1"
github "snowplow/snowplow-objc-tracker" "1.1.2"
github "suzuki-0000/SKPhotoBrowser" "6.1.0"

[morganchen12]

A few thoughts from looking at the stack trace:

• The GTMSessionFetcher code tries to load some persisted background fetchers from NSUserDefaults. This usually only takes a few milliseconds; something unusual in your app is causing this to hang for longer. You can see the load logic in its entirety here.
• The thing that's taking up your launch time is NSUserDefaults, which seems to be retrying a fetch from CFPreferences that's failing over and over again. See this part of the stack trace:
  5 CoreFoundation 0x000000018967a804 __78-[CFPrefsPlistSource sendRequestNewDataMessage:toConnection:retryCount:error:]_block_invoke + 28 6 CoreFoundation 0x00000001896b2abc CFPREFERENCES_IS_WAITING_FOR_SYSTEM_CFPREFSD + 48 7 CoreFoundation 0x000000018964d15c -[CFPrefsPlistSource sendRequestNewDataMessage:toConnection:retryCount:error:] + 256 8 CoreFoundation 0x00000001896439fc -[CFPrefsPlistSource handleErrorReply:fromMessageSettingKey:toValue:retryCount:retryContinuation:] + 1348 9 CoreFoundation 0x000000018963b5f4 -[CFPrefsPlistSource handleReply:toRequestNewDataMessage:onConnection:retryCount:error:] + 196 10 CoreFoundation 0x000000018964d184 -[CFPrefsPlistSource sendRequestNewDataMessage:toConnection:retryCount:error:] + 296 11 CoreFoundation 0x00000001896439fc -[CFPrefsPlistSource handleErrorReply:fromMessageSettingKey:toValue:retryCount:retryContinuation:] + 1348 12 CoreFoundation 0x000000018963b5f4 -[CFPrefsPlistSource handleReply:toRequestNewDataMessage:onConnection:retryCount:error:] + 196 13 CoreFoundation 0x000000018964d184 -[CFPrefsPlistSource sendRequestNewDataMessage:toConnection:retryCount:error:] + 296
• GTMSessionFetcher could potentially move this logic from load to initialize, but that's not guaranteed to fix the crash at launch or the hang from NSUserDefaults.

Do you have a reproducible example you could share? Also, do you know if the crash is occurring on non-jailbroken devices?

[morganchen12]

cc @thomasvl

[thomasvl]

https://github.com/google/gtm-session-fetcher/pull/154 is looking to move this off +load further into startup to avoid some of the delays.

[icedice]

Unfortunately we are unable to reproduce it consistently.
In fact we only have one device where this happens again and again (but not every time), the device is not jailbroken. This device belongs to one of our main stakeholders, which is also part of the problem.
It could be some "freak" issue with this device I guess, especially since we can't reproduce it on any of our 10+ test devices, but it's a major concern if our end-users experience this and that's why I try digging deeper, especially because our crash reporting would be unaware of 8badf00d I guess.

[adamup928]

@icedice - does your application use the data protection entitlement, by chance? There's an iOS 13 bug that causes crashes due to the scene-update watchdog timer when data protection is enabled.

Here's an Apple developer forum post that includes some reproduction steps so you can verify it's affecting you: https://forums.developer.apple.com/thread/122858

[morganchen12]

Looks like the stack trace in the parent issue has a different exception message (EXC_CRASH / SIGKILL) than the iOS 13 bug crash, so it's probably unrelated.

@icedice, you can try patching in https://github.com/google/gtm-session-fetcher/pull/154 and seeing if that fixes the crash. Otherwise, without a reproducible sample we won't be able to help you resolve this issue.

[adamup928]

@morganchen12 - I can confirm that the exception message (EXC_CRASH / SIGKILL) is what's given as a result of the data protection entitlement watchdog crash.

[morganchen12]

The apple developer forum link you posted is a SIGBUS crash.

[adamup928]

@morganchen12 - yes, that initial post you're seeing is a different issue. There is a thread on that page, however, that talks about the data protection entitlement crash. Sorry for the confusion. There's no way to link directly to specific posts in the Apple dev forum.

[morganchen12]

I see, thanks for clarifying!

[icedice]

@icedice - does your application use the data protection entitlement, by chance? There's an iOS 13 bug that causes crashes due to the scene-update watchdog timer when data protection is enabled.

Here's an Apple developer forum post that includes some reproduction steps so you can verify it's affecting you: https://forums.developer.apple.com/thread/122858

The device in question runs iOS 12.4 and we do not have any data protection entitlement set. So I think the linked issue is unrelated.

[morganchen12]

Closing this issue since it's not actionable here. Please let us know if patching in https://github.com/google/gtm-session-fetcher/pull/154 doesn't fix it and I'll reopen the issue.