Firebase-ios-sdk: Crashed: com.google.fira.worker EXC_BAD_ACCESS KERN_INVALID_ADDRESS

[harryhiyoshi]

Step 0: Are you in the right place?

• For issues or feature requests related to __the code in this repository__
  file a Github issue.
  
  
  
  • If this is a __feature request__ please use the Feature Request template.
  
  
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.5
• Firebase SDK version: 6.30.0
• Firebase Component: Core (6.30.0), Analytics (6.30.0), Crashlytics (6.30.0), Messaging (6.30.0, 4.6.1), Performance (6.30.0), ABTesting (4.2.0), Installations (1.6.0), InstanceID (4.5.1), CoreDiagnostics (1.5.0)
• Component version: please check above
• Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem

When a 3rd party SDK for monitoring was enabled, crashes happened at Firebase. The crash rate is not so high, so it is difficult to reproduce it. Can you help sort it out, since both tools are needed for us?

Steps to reproduce:

I have not been able to reproduce it so far.

//stacktrace
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000bd73b3800
Crashed: com.google.fira.worker
0 libobjc.A.dylib 0x1b4a82aa0 objc_release + 16
1 libobjc.A.dylib 0x1b4a8404c AutoreleasePoolPage::releaseUntil(objc_object**) + 180
2 libobjc.A.dylib 0x1b4a83f44 objc_autoreleasePoolPop + 224
3 libdispatch.dylib 0x1b4a0b504 _dispatch_last_resort_autorelease_pool_pop + 40
4 libdispatch.dylib 0x1b49b82f4 _dispatch_lane_invoke$VARIANT$mp + 512
5 libdispatch.dylib 0x1b49c178c _dispatch_workloop_worker_thread + 588
6 libsystem_pthread.dylib 0x1b4a5cb74 _pthread_wqthread + 272
7 libsystem_pthread.dylib 0x1b4a5f740 start_wqthread + 8
com.apple.main-thread

//podfile.lock

• Firebase SDK version / FirebaseComponent / Component version:
  
  
  
  • Firebase (6.30.0):
  
  
  • Firebase/Core (= 6.30.0)
  
  
  • Firebase/Analytics (6.30.0):
  
  
  • Firebase/Core
  
  
  • Firebase/Core (6.30.0):
  
  
  • Firebase/CoreOnly
  
  
  • FirebaseAnalytics (= 6.7.2)
  
  
  • Firebase/CoreOnly (6.30.0):
  
  
  • FirebaseCore (= 6.10.0)
  
  
  • Firebase/Crashlytics (6.30.0):
  
  
  • Firebase/CoreOnly
  
  
  • FirebaseCrashlytics (~> 4.4.0)
  
  
  • Firebase/DynamicLinks (6.30.0):
  
  
  • Firebase/CoreOnly
  
  
  • FirebaseDynamicLinks (~> 4.2.1)
  
  
  • Firebase/Messaging (6.30.0):
  
  
  • Firebase/CoreOnly
  
  
  • FirebaseMessaging (~> 4.6.1)
  
  
  • Firebase/Performance (6.30.0):
  
  
  • Firebase/CoreOnly
  
  
  • FirebasePerformance (~> 3.3.0)
  
  
  • FirebaseABTesting (4.2.0):
  
  
  • FirebaseCore (~> 6.10)
  
  
  • FirebaseAnalytics (6.7.2):
  
  
  • FirebaseCore (~> 6.8)
  
  
  • FirebaseInstallations (~> 1.4)
  
  
  • GoogleAppMeasurement (= 6.7.2)
  
  
  • GoogleUtilities/AppDelegateSwizzler (~> 6.7)
  
  
  • GoogleUtilities/MethodSwizzler (~> 6.7)
  
  
  • GoogleUtilities/Network (~> 6.7)
  
  
  • "GoogleUtilities/NSData+zlib (~> 6.7)"
  
  
  • nanopb (~> 1.30905.0)
  
  
  • FirebaseCore (6.10.0):
  
  
  • FirebaseCoreDiagnostics (~> 1.3)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • GoogleUtilities/Logger (~> 6.7)
  
  
  • FirebaseCoreDiagnostics (1.5.0):
  
  
  • GoogleDataTransport (~> 7.0)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • GoogleUtilities/Logger (~> 6.7)
  
  
  • nanopb (~> 1.30905.0)
  
  
  • FirebaseCrashlytics (4.4.0):
  
  
  • FirebaseCore (~> 6.10)
  
  
  • FirebaseInstallations (~> 1.6)
  
  
  • GoogleDataTransport (~> 7.2)
  
  
  • nanopb (~> 1.30905.0)
  
  
  • PromisesObjC (~> 1.2)
  
  
  • FirebaseDynamicLinks (4.2.1):
  
  
  • FirebaseCore (~> 6.10)
  
  
  • FirebaseInstallations (1.6.0):
  
  
  • FirebaseCore (~> 6.10)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • GoogleUtilities/UserDefaults (~> 6.7)
  
  
  • PromisesObjC (~> 1.2)
  
  
  • FirebaseInstanceID (4.5.1):
  
  
  • FirebaseCore (~> 6.8)
  
  
  • FirebaseInstallations (~> 1.0)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • GoogleUtilities/UserDefaults (~> 6.7)
  
  
  • FirebaseMessaging (4.6.1):
  
  
  • FirebaseCore (~> 6.8)
  
  
  • FirebaseInstanceID (~> 4.3)
  
  
  • GoogleUtilities/AppDelegateSwizzler (~> 6.7)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • GoogleUtilities/Reachability (~> 6.7)
  
  
  • GoogleUtilities/UserDefaults (~> 6.7)
  
  
  • Protobuf (>= 3.9.2, ~> 3.9)
  
  
  • FirebasePerformance (3.3.0):
  
  
  • FirebaseCore (~> 6.9)
  
  
  • FirebaseInstallations (~> 1.5)
  
  
  • FirebaseRemoteConfig (~> 4.7)
  
  
  • GoogleDataTransport (~> 7.0)
  
  
  • GoogleToolboxForMac/Logger (~> 2.1)
  
  
  • "GoogleToolboxForMac/NSData+zlib (~> 2.1)"
  
  
  • GoogleUtilities/Environment (~> 6.2)
  
  
  • GoogleUtilities/ISASwizzler (~> 6.2)
  
  
  • GoogleUtilities/MethodSwizzler (~> 6.2)
  
  
  • GTMSessionFetcher/Core (~> 1.1)
  
  
  • Protobuf (~> 3.12)
  
  
  • FirebaseRemoteConfig (4.9.0):
  
  
  • FirebaseABTesting (~> 4.2)
  
  
  • FirebaseCore (~> 6.10)
  
  
  • FirebaseInstallations (~> 1.6)
  
  
  • GoogleUtilities/Environment (~> 6.7)
  
  
  • "GoogleUtilities/NSData+zlib (~> 6.7)"
  
  

Relevant Code:

[maksymmalyhin]

@harryhiyoshi The issue looks like a duplicate of #6318. Could you please try troubleshooting steps suggested in #6318 and update the thread.

[harryhiyoshi]

No good results with sanitizer tool so far. I could confirm only that the crash never happened with disabling the monitoring tool.

I got following comments about the crash from the monitoring tool vender. Appreciate your help to stop the Crash in Firebase.

-It happens on draining an autorelease pool
-It occurs on a thread of firebase not associated with our agent threads
-Our agent only uses autorelease pools in named threads

In conclusion, it is highly unlikely that our agent causes this.
Even if it only happens in conjunction with our agent, this still is a bug in google code. We cannot influence their code’s memory management, and we cannot release any objects not created by our agent.

[maksymmalyhin]

@harryhiyoshi Thank you for the update. Yeah, so far everything points out to a potential issue on the Firebase side. There are couple things I would like to ask you to help with the investigation:

1. An issue with autorelease pool (a memory management in general) may occur because of incorrect bridging between CoreFoundation, Objective-C and Swift types. Could you please check what parameters are passed to Analytics by the app. Could you please provide examples of the parameters if it is more than just string literals?

2. Could you please try to create a sample project to reproduce the issue? Without it it is very difficult to make progress on the issue.

[harryhiyoshi]

Thank you for the comment. Though it is not possible to reproduce, what sample app do you need? Is it enough with an app including both the monitoring tool and Firebase?

[maksymmalyhin]

We will need a sample app where the crash was reproduced at least once.

[harryhiyoshi]

Understood, thank you. Can I sent it to you not here but with a secure way to keep all privacy?

[maksymmalyhin]

@harryhiyoshi Sure, feel free to use the email [email protected] for it.

[harryhiyoshi]

Hi @maksymmalyhin,
Thank you for your support. As for #1, either NSTaggedPointerString, __NSCFNumber or __NSCFString is used as parameter.
As for #2, I understand a sample is needed to investigate though, it is difficult to reproduce actually. We tried it for 2 days, but we couldn't. The crash rate is not so high but the impact is high since we have massive number of users.
Appreciate your help.

[maksymmalyhin]

Thank you for the update. We will try to find possible reasons of the issue on our side. A couple more things that may help the investigation:

• would you be able to send a full crash log. It may contain some additional clues. Feel free to send it privately to [email protected]
• could you check if your app or one of it's dependencies uses objc_sync_enter and objc_sync_exit for synchronization? We've noticed that this may cause crashes in unrelated parts of the app (e.g. #5998). Or maybe you are aware of another undocumented API usage?

[harryhiyoshi]

Hi @maksymmalyhin , Thank you for your investigation and updates. I have posted a full stacktrace to the email address. I hope it may help you. As for #2, I will check it later.

[maksymmalyhin]

@harryhiyoshi Thank you. From the first glance I could not spot anything suspicious in the call stack. I'll pass it to Firebase Analytics team for investigation.

[maksymmalyhin]

Tracked internally at b/167426485

[harryhiyoshi]

Hi @maksymmalyhin,

could you check if your app or one of it's dependencies uses objc_sync_enter and objc_sync_exit for synchronization?

The app: Yes
A library(RxSwift): Yes
The 3rd party monitoring tool: No

I hope it may help your investigation.

[maksymmalyhin]

If objc_sync_... methods are used in your app, I highly recommend to refactor the code to avoid using the methods (and/or contact the library owner to do it). As mentioned in #5998 the methods are not intended to be used directly and proved to lead to issues.

[harryhiyoshi]

Thnak you @maksymmalyhin for your advice, OK, I will try that.

[maksymmalyhin]

@harryhiyoshi An update on if the issue was fixed for you is appreciated. It will definitely help us and other developers if they encounter a similar issue.