Suddenly FBSDKRestrictiveDataFilterManager.m - Line 71 started to crash

[chuganzy]

Checklist

• I've updated to the latest released version of the SDK
• I've searched for existing GitHub issues
• I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group
• I've read the Code of Conduct
• This issue is not security related and can safely be disclosed publicly on GitHub

Crash

It suddenly started to crash from 14:44 PST 5/6/2020.
Assuming that something is going wrong in Facebook API server.

for (NSString *eventName in restrictiveParams.allKeys) {
    if (restrictiveParams[eventName][@"is_deprecated_event"]) { // <- here crashes
	    [deprecatedEventSet addObject:eventName];
    }
    if (restrictiveParams[eventName][@"restrictive_param"]) {
	    FBSDKRestrictiveEventFilter *restrictiveEventFilter = [[FBSDKRestrictiveEventFilter alloc] initWithEventName:eventName
                                                                                                        eventParams:restrictiveParams[eventName][@"restrictive_param"]];
    	[eventFilterArray addObject:restrictiveEventFilter];
    }
}

Environment

FBSDKCoreKit (5.11.0)

• Xcode Version: 11.4.1
• Installation Platform & Verison: CocoaPods

Goals

Solve the crashing issue

Expected Results

Solve the crashing issue

Actual Results

Crashing

Steps to Reproduce

N/A

Code Samples & Details

N/A

[jstheoriginal]

Started crashing for us at 4:43pm as well (~40 minutes ago).

[GLJeffery]

We are also experiencing this at 4:46 EST

[jstheoriginal]

Possibly something was turned on remotely for the new 7.0.0 release that just got published?

[narlei]

Here too, started some hours ago.

For me, I can only see in crashalytics:

Fatal Exception: NSInvalidArgumentException
-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x200729d00
-[NSOrderedSet initWithSet:copyItems:]

[kevinmbeaulieu]

We're seeing this on version 5.15.1, if that helps

[Abeansits]

When you guys revert, is that an immediate rollout or is it phased? @tianqibt

[kevinmbeaulieu]

@tianqibt I'm still able to repro the crash. Has the revert been deployed?

[narlei]

No more crashes here too. Thanks for solve fast.

[GLJeffery]

@tianqibt I'm still able to repro the crash. Has the revert been deployed?

If you don't mind, what were your replication steps? It feels like it's not 100% crash rate but just some users.

[marksvend]

Our crash is happening to 40% of new app starts. It has not dropped yet.

[hberberoglu]

We are also experiencing this. It started ~1 hour ago.

[kevinmbeaulieu]

I literally just ran our app in the iOS simulator and it crashed on launch. Didn't do any special setup.
And I seem to be getting the crash 100% of the time in my simulator
Update (3:50PM PST): Not seeing the crash in the simulator anymore

[mmdock]

Looks like it stopped for us based on Crashlytics, but keeping an eye on other crash numbers and gonna try the build manually soon.

[marksvend]

This is still a major problem for us. 47% of app starts are still crashing.

[john-mejia]

This seems to still be happening, and I notice a lot of my other production apps (not owned by me)

[mgray88]

We're still seeing issues in Sentry, and I'm reproducing this in the simulator

[chrismcs]

Still a major issue for us as well - we're reproducing 100% crash on launch for our production apps

[paulbruneau]

Our rate has dropped as reported by New Relic. Not down to zero yet.

[scelis]

Our app is definitely still crashing on launch as well.

[marksvend]

It appears the cause is this configuration the Facebook SDK is receiving from the mothership for restrictiveParams:

"restrictive_data_filter_params" = "{"is_health_app":false}";

The value is expected to be a dictionary, not a BOOL.

[Abeansits]

@tianqibt can you speak more to how your rollback strategy works? When can we expect a 100% rollout?

[PatrickDanino]

This raises a number of questions beyond this particular incident:

• What features are being remotely controlled?
• Why are those features being loaded at launch time?
• Where is all of this documented?
• Could this be used as a kill switch for 3rd party apps?
• Can we turn this off?

[prachigauriar]

Grubhub is seeing a significant number of crashes on launch still. Multiple relaunches seems to solve the problem.

[patrickweekes]

The crash is still reproducible for us in the simulator when we launch the app:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x7fff8061ea20'

[malonehedges]

We're still seeing a lot of crashes on our app as well

[ripalsanghani]

We're also experiencing a high level of crashes

[RealBug]

Same for us 😢

[mmdock]

UPDATE: even though I am not seeing new crashes in Crashlytics, strangely still seeing this crash occur on simulator and when i build to my device. I wonder if Crashlytics went down because of the number of crash reports they are receiving from this

[rancaka]

thanks for quick solving guys 🙏🏻, it was creating new pandemic in my country 🇮🇩

[mmdock]

@jschwab923 haha that's what i did. I found it way after everyone else mentioned it, so wasn't sure if there was a better / faster way to debug this

[BennyTheNerd]

Dear Facebook QA,

This was a bad bug. Please be more considerate next time, but thank you for fixing relatively quickly.

ps. might be best to try the standard industry practice of testing new things during non-peak hours.

[patrickmarshall]

The crash seems to be resolved on our apps.
Thank you FB team for the speedy response :)
I hope something like this will never happen anymore in the future.
.
and also hoping that c-virus pandemic can be resolved as fast as this issue XD

[jwshaffstall]

Is there some client-side mitigation that can be used to prevent this SDK from taking down whole apps in the future?

[mmdock]

@jwshaffstall we bend at the will of the Facebook overlords

[nicorichard]

Some have reported that the crash appears to be resolved. The Firebase team is now reporting that iOS crash processing has been suspended. Which confirms my fears, as we're seeing no activity at all (crashes or non-fatals)

If you're using Firebase Crashlytics as your metric for this being resolved it cannot be currently trusted.

Source: https://status.firebase.google.com/incident/Crashlytics/20003

[marcofung]

There was 5K crashes reported via Firebase Crashlytics before reporting stopped. While other crash reporting service showed that there have been over 30K crashes till now. It's still happening a minute ago.

[wode-liu]

what version are you guys using? we are using 5.4.0, it seems ok.

[Guo8a]

40% crash rate😭
差点丢了饭碗

[marcofung]

what version are you guys using? we are using 5.4.0, it seems ok.

Using version 5.15.1. We are afraid that the crash issue on the affected sessions wouldn't be resolved quickly as we still see incoming tracked crash reports. Supposed the fix has been rolled out for quite a while, the new session shouldn't be affected. The incoming crashes would probably mean a repeated occurrence, which means the clients are unable to fetch or apply the fixed version before it crashes on launch.

[WangGeBing]

we are using 5.7.0, which also had this problem and was serious😭

[tyrchen]

"restrictive_data_filter_params" = "{"is_health_app":false}";
The value is expected to be a dictionary, not a BOOL.

Can't believe this is happening. I'm pretty curious if facebook would publish a post mortem on this. Looks like this server change should be captured by code review, or unit testing, or so.

[nicolas17]

Looks like this server change should be captured by code review, or unit testing, or so.

The client should also be resilient to such server changes.

[krunalsshah]

Our iOS app is still reporting crashes, for others, have your app's recovered 100%?
Snippet from our error monitoring & reporting tool, still alerting the crash.

-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x1e8da5d00

Anyone from the Facebook core team can provide a detailed analysis of the problem?

The question to the Facebook core team

Can we have a configuration to lazy load the initialization only when the app feature requires it?

[jpwang1208]

Facebook 不靠谱啊

[dongshuju]

100% Crash when launching app. 😡

[WangGeBing]

I was wondering if it might have something to do with the way the installation was done，CocoaPods is false，FBSDKCoreKit.framework is true? Maybe I'm wrong!Who can test it?I can't reproduce it

[dongshuju]

We try to fix the crash by using remote config to turn off the FBSDK, It's not working.
Even if you don't enable FBSDK, it still crashes. Because they start it in '+load' method.

[revolter]

I was wondering if it might have something to do with the way the installation was done，CocoaPods is false，FBSDKCoreKit.framework is true? Maybe I'm wrong!Who can test it?I can't reproduce it

It doesn't.

[Sin-]

Is it really the automatic events logging that causes this crash?
We don't use the Analytics of the FBSDK so I will disable the Automatically Logged Events from the Info.plist and the Manifest
Links for reference to disable them:
Android
iOS

[davidmwest]

Hkjtkthutitjtjtjjjjjui try

[davidmwest]

Ancdefghijklmnksrkrrrhrrfuur t

[msosnin]

I had had Automatic events logging disabled, however also noticed a lot of crashes during same period

[liamnichols]

If you're only using this SDK for social auth, and you don't support below iOS 11 then its easier to just use SFAuthenticationSession/ASWebAuthenticationSession instead.

The docs for OAuth are here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow

It was a lot easier to switch than I was expecting.

[tianqibt]

A new release of Facebook included a change that triggered crashes for some users in some apps using the Facebook iOS SDK. We identified the issue quickly and resolved it. We apologize for any inconvenience

[gamafranco]

A new release of Facebook included a change that triggered crashes for some users in some apps using the Facebook iOS SDK. We identified the issue quickly and resolved it. We apologize for any inconvenience

#1373 (comment)