Firebase-ios-sdk: Crash : Audience filter count out of range

[gaurav02712]

Environment

• Xcode version: 9.4.1
• Firebase SDK version: 5.2.0

Describe the problem
Every time I open the app go the same issue/crash

5.2.0 - [Firebase/Analytics][I-ACS006009] Audience definition is invalid. Audience will not be saved. Audience, error: <FIRAPBAudience: 0x604000203860>, Error Domain=com.google.gmp.measurement.ErrorDomain Code=9 "Audience filter count out of range"

[baolocdo]

Please ignore this. This is a known bug from the BE, not the SDK but it won't interfere with the normal operation of the SDK. Sorry for the confusion :(

[gaurav02712]

But I am getting this more often and this is not just error which I can ignore as that is producing a crash also.

[baolocdo]

Hmm, I haven't seen the crash related to this message. Do you have any crash log related to this? Can you please provide some sample project so we can reproduce the bug? Thank you.

[gaurav02712]

What i am gettign is -
Domain=FABNetworkError Code=-6 "(null)" UserInfo={retryLimit=1, NSErrorFailingURLStringKey=https://settings.crashlytics.com/spi/v2/platforms/ios/apps/com.t9l.hospalsapp/settings?build_version=1&display_version=1.0&instance=62d1e8f04ff57b97339b93f996369f0847e308e5&source=1}

Screeshot:- for more detail

[baolocdo]

Can you provide the stack trace here? The screenshot is cut off so I can't tell which SDK (Analytics, or other Firebase SDK) is causing the crash. I don't think the Audience warning is related to the Network error since you should have successful network connection to receive the Audience. Therefore, it is unlikely related but I'd like to know the real cause of the crash to fix. Thank you!

[gaurav02712]

I am not getting this very often and not always on debug mode so give the screenshot like above again is little bit difficult for me. But once I got it the same, will update it here again. Till there is something very clear that it is in Firebase core framework, FIRMutableDictionary class and line number also.

[gaurav02712]

Find a more detailed screenshot which i got on debugging
It is trying to removing an object with key "com.firebase.network.background-upload-B6A85FD7-580E-4B37-AF64-1088A6B242C4" from a blank dictionary

[baolocdo]

Thanks for providing the screenshot. I think this is related to this issue https://github.com/firebase/firebase-ios-sdk/issues/1317#issuecomment-397908981, and not the error message in the device log. Since the message is logged before Analytics uploads some events, that leads to the network crash, it makes them related.
@paulb777, @ryanwilson : Can we revisit this again or provide the code snippet of the potential fix in this open sourced code to @GauravT9l so they can verify whether it helps alleviate the issue? Thanks

[ryanwilson]

The fix for #1317 was shipped with Firebase 5.5.0 last week, so it's worth updating and seeing if you can reproduce.

The code snippet on the open source side never shipped as we determined it was attempting to fix an impossible state. #1426 for reference.

[gaurav02712]

Update all the pod yesterday and firebase too with current version Firebase 5.5.0.
Now getting error in Google Utility pod GULMutableDictionary.m . Not sure this is using by firebase or not. but as i got same error so posting here, may b this could help to figure out something.

[baolocdo]

Yes, it has been renamed and moved to GoogleUtilities pod so it is still the same issue.
@paulb777 : I still think the unreleased fix could fix this. Can we please provide it to @GauravT9l to try since they can reproduce the issue? It is worth trying

[paulb777]

@baolocdo Do you mean #1426?
Based on this crash log, it doesn't seem that weakify'ing self would help since the crash looks to be the result of a deallocated (and zombified object) stored in the NSMutableDictionary.

[baolocdo]

Yes, since it was deallocated, it shouldn't be referenced anymore in that async block. The async block can be scheduled and run after the object self has been already deallocated. We can confirm whether the fix can help in this case by providing to @GauravT9l instead of saying it doesn't help. Since the new release didn't fix the crash, we can try another potential fix. Is there any reason why we are opposing this?

[morganchen12]

Pasting this from the email thread earlier last week:

I don't think self is the value that's being zombified here. The call to __dealloc_zombie happens after removeObjectForKey: is invoked, so the refcount being decremented belongs to whatever object is being removed from the dictionary. A few things to note:

• This isn't a proper zombies exception, just a crash that happened when zombies were enabled. Notably, __dealloc_zombie was called without raising an exception, so at the point where the object is deallocated it's being deallocated properly (it's not already a zombie).
• The program then crashes in the C method used by zombies to turn deallocated instances of objects into zombies instead of actually deallocating them.

I don't have a good conclusion for what's going on here, but I don't think using weak self will fix it. If we could get the description of the object being deallocated (the object released by removeObjectForKey:) it'd be a lot more clear what's happening.

[paulb777]

Would it be reasonable to switch GULMutableDictionary's internal type from NSMutableDictionary to a Strong-to-Weak NSMapTable?

How should the lifetime of the GULNetworkURLSessions that get stored as values in the GULMutableDictionary be managed?

[baolocdo]

No, please do not change it NSMapTable as this is supposed to be an NSMutableDictionary. Otherwise, we can just use NSMutableDictionary in the GULNetworkURLSession and it might cause other crashes due to thread unsafety. Again, I'm don't fully agree with the email thread and I'd like to give it a try to verify the hypothesis. If it doesn't work, we can find another solution instead of keep saying it is not happening.

[paulb777]

@GauravT9l Are you able to share a reproducible example?

Otherwise you could try out some of the changes in #1426 or other ideas discussed in this thread.

[morganchen12]

My guess is the object in the dictionary is getting clobbered elsewhere and it makes less sense to be extra defensive here than it does to figure out where the object is being mangled and un-mangle it there.

[morganchen12]

Closing for now; we'll reopen this when we have more information.

[maranas]

I can reproduce this consistently when enabling zombie objects AND malloc scribble. It seems the object in the dictionary is sent a message after it is removed.

[paulb777]

@maranas What are your Firebase pod versions?

[maranas]

@paulb777 Just updated to Firebase/Core 5.10.0. I see the same stack trace posted by @GauravT9l (crash after removing a GULNetworkURLSession instance in the dictionary) but now it happens in GULMutableDictionary (in GoogleUtilities/Network v5.3.2).

When it crashes, the "zombie object" is always the URL session with the kGULNetworkBackgroundSessionConfigIDPrefix prefix. Interesting is that the crash happens after removing the object from the dictionary, and only happens if both zombie objects and malloc scribble are enabled.

The file here in the screenshot is GULMutableDictionary.m

[maranas]

@paulb777 One big thing i forgot in the previous message - the issue happens only on iOS 9. Or at least i can only reproduce it there.

[paulb777]

@maranas I'm not able to reproduce in a sample app on iOS 9 with zombie objects and malloc scribble enabled.

Are you able to share a reproducible example - or reproduce in one of the quickstarts?

[mqln]

Hello, I'm experiencing this crash intermittently on iOS 11.3 in the Simulator.

Is this a persisting problem?

[morganchen12]

@mqln can you share a stack trace?

[mqln]

@morganchen12 Absolutely, here's some more info:

* thread #2, queue = 'GULMutableDictionary', stop reason = EXC_BAD_ACCESS (code=1, address=0x2)
  * frame #0: 0x000000010d18bc38 libobjc.A.dylib`object_setClass + 116
    frame #1: 0x000000010dc0e51e CoreFoundation`-[NSObject(NSObject) __dealloc_zombie] + 158
    frame #2: 0x000000010d19fdcc libobjc.A.dylib`objc_object::sidetable_release(bool) + 202
    frame #3: 0x000000010f992595 libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #4: 0x000000010f993602 libdispatch.dylib`_dispatch_client_callout + 8
    frame #5: 0x000000010f99ab0b libdispatch.dylib`_dispatch_lane_serial_drain + 791
    frame #6: 0x000000010f99b784 libdispatch.dylib`_dispatch_lane_invoke + 428
    frame #7: 0x000000010f9a589a libdispatch.dylib`_dispatch_workloop_worker_thread + 733
    frame #8: 0x000000010fd7efd2 libsystem_pthread.dylib`_pthread_wqthread + 980
    frame #9: 0x000000010fd7ebe9 libsystem_pthread.dylib`start_wqthread + 13

Plus, here's the relevant portion of my Podfile.lock

- FBSDKCoreKit (4.31.1):
    - Bolts (~> 1.7)
  - FBSDKLoginKit (4.31.1):
    - FBSDKCoreKit
  - Firebase/Analytics (5.12.0):
    - Firebase/Core
  - Firebase/Auth (5.12.0):
    - Firebase/CoreOnly
    - FirebaseAuth (= 5.0.5)
  - Firebase/Core (5.12.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 5.3.0)
  - Firebase/CoreOnly (5.12.0):
    - FirebaseCore (= 5.1.7)
  - Firebase/Firestore (5.12.0):
    - Firebase/CoreOnly
    - FirebaseFirestore (= 0.14.0)
  - Firebase/Messaging (5.12.0):
    - Firebase/CoreOnly
    - FirebaseMessaging (= 3.2.1)
  - Firebase/Performance (5.12.0):
    - Firebase/Core
    - FirebasePerformance (= 2.2.1)
  - Firebase/RemoteConfig (5.12.0):
    - Firebase/Core
    - FirebaseRemoteConfig (= 3.1.0)
  - Firebase/Storage (5.12.0):
    - Firebase/CoreOnly
    - FirebaseStorage (= 3.0.3)
  - FirebaseABTesting (2.0.0):
    - FirebaseCore (~> 5.0)
    - Protobuf (~> 3.5)
  - FirebaseAnalytics (5.3.0):
    - FirebaseCore (~> 5.1)
    - FirebaseInstanceID (~> 3.3)
    - GoogleAppMeasurement (~> 5.3)
    - GoogleUtilities/AppDelegateSwizzler (~> 5.2)
    - GoogleUtilities/MethodSwizzler (~> 5.2)
    - GoogleUtilities/Network (~> 5.2)
    - "GoogleUtilities/NSData+zlib (~> 5.2)"
    - nanopb (~> 0.3)
  - FirebaseAnalyticsInterop (1.1.0)
  - FirebaseAuth (5.0.5):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.1)
    - GoogleUtilities/Environment (~> 5.2)
    - GTMSessionFetcher/Core (~> 1.1)
  - FirebaseAuthInterop (1.0.0)
  - FirebaseCore (5.1.7):
    - GoogleUtilities/Logger (~> 5.2)
  - FirebaseFirestore (0.14.0):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.1)
    - FirebaseFirestore/abseil-cpp (= 0.14.0)
    - "gRPC-C++ (~> 0.0.3)"
    - gRPC-ProtoRPC (~> 1.0)
    - leveldb-library (~> 1.20)
    - nanopb (~> 0.3.8)
    - Protobuf (~> 3.1)
  - FirebaseFirestore/abseil-cpp (0.14.0):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.1)
    - "gRPC-C++ (~> 0.0.3)"
    - gRPC-ProtoRPC (~> 1.0)
    - leveldb-library (~> 1.20)
    - nanopb (~> 0.3.8)
    - Protobuf (~> 3.1)
  - FirebaseInstanceID (3.3.0):
    - FirebaseCore (~> 5.1)
    - GoogleUtilities/Environment (~> 5.3)
    - GoogleUtilities/UserDefaults (~> 5.3)
  - FirebaseMessaging (3.2.1):
    - FirebaseAnalyticsInterop (~> 1.1)
    - FirebaseCore (~> 5.1)
    - FirebaseInstanceID (~> 3.0)
    - GoogleUtilities/Environment (~> 5.2)
    - GoogleUtilities/Reachability (~> 5.2)
    - Protobuf (~> 3.1)
  - FirebasePerformance (2.2.1):
    - FirebaseAnalytics (~> 5.3)
    - FirebaseInstanceID (~> 3.3)
    - FirebaseRemoteConfig (~> 3.1)
    - GoogleToolboxForMac/Logger (~> 2.1)
    - "GoogleToolboxForMac/NSData+zlib (~> 2.1)"
    - GoogleUtilities/ISASwizzler (~> 5.2)
    - GoogleUtilities/MethodSwizzler (~> 5.2)
    - GTMSessionFetcher/Core (~> 1.1)
    - Protobuf (~> 3.5)
  - FirebaseRemoteConfig (3.1.0):
    - FirebaseABTesting (~> 2.0)
    - FirebaseAnalytics (~> 5.3)
    - FirebaseCore (~> 5.1)
    - FirebaseInstanceID (~> 3.3)
    - GoogleUtilities/Environment (~> 5.2)
    - "GoogleUtilities/NSData+zlib (~> 5.2)"
    - Protobuf (~> 3.5)
  - FirebaseStorage (3.0.3):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.1)
    - GTMSessionFetcher/Core (~> 1.1)
  - FirebaseSwizzlingUtilities (1.0.0)

[morganchen12]

Do you have the exception message as well? That will (hopefully) tell us what class is getting deallocated, which may help track the issue down.

[mqln]

Sure, here's some more info dumping:

-[fir_0x6000024c5f20_GULNetworkURLSession respondsToSelector:]: message sent to deallocated instance 0x6000024c5f20
105553154826016

line & error within object_setClass

41: 0x10fcecc38 <+116>: testb  $0x40, 0x2(%rax)

Thread 10: EXC_BAD_ACCESS (code=1, address=0x2)

Aaanndd a screenshot for good measure.
This seems to happen like 1 in 12 times upon app launch.
Anything else I can send along to help?

[paulb777]

@mqln Do you see the same issue with a more recent Firebase version. The current release is 5.16.0.

[mqln]

@paulb777 Let me update and stress-test and see if I can reproduce, good call.

[mberndt92]

@morganchen12 : I can still see the issue appearing a lot for us using 5.16.0
Interestingly some of us use AppCode where the issue seems to be absent entirely.

[mberndt92]

For anyone still struggling with this crash.
What worked for our project is disabling the NSZombieEnabled environment variable.
Just remember that this results in a loss of proper Memory Debugging so in case you need to do that, don't forget to re-enable it.

[morganchen12]

This does look a little different than the original issue (the crash is caused by a different selector).

I haven't had time to take a look at this yet, but I suspect looking at the ownership of GULNetworkURLSession would be a good place to start.

[pmusolino]

Same crash here...
i've the last version of the firebase ios sdk installed

[amaldona]

Same, pods has been updated. I'm experiencing this crash intermittently as well

[ryanwilson]

@pmusolino @amaldona are you using any post-processing steps on the .ipa? I've seen something similar before when a developer was using Citrix to upload their .ipa for obfuscation. Thought it would be worth a shot to see if something similar is being done on your project's artifacts.

[morganchen12]

Closing due to inactivity and heavy fragmentation. If you're running into an Analytics crash, please open a new issue.