Segmentation Fault: 11 after upgrading past 6.32.0 #6734
Comments
|
I suspect Performance is doing something bad. Can you try excluding Performance? |
|
@tspecht Sorry you have the issue. From the first glance the crash indicates a concurrent memory access somewhere around
Please share the results so we can think of the next steps. Note: It also may be related to #6713. |
|
@maksymmalyhin I did try running with the different checkers, unfortunately nothing interesting came out of this. Not sure what you mean by point #2? |
|
@tspecht I mean setting isInstrumentationEnabled. It allows you to keep custom performance traces(if you use them) but disable metrics collected automatically that imply swizzling, etc. |
|
@maksymmalyhin currently running our CI steps a bunch of times which takes a while, first pass with |
|
@tspecht Thank you! |
|
@maksymmalyhin ran it two additional times and still seeing crashes: |
|
@tspecht is the crash with |
|
@maksymmalyhin unfortunately yes, calling the following as part of my |
|
@tspecht It most likely indicates that the crash is not related to Performance SDK. Just to be more sure on it, could you please test with Firebase Performance excluded from your app? |
|
@maksymmalyhin we just finished running 5 builds in a row without the Previously we used to have a failure rate of roughly 2 out of 3 builds failing due to the crash mentioned above. While this isn't proof, I think statistically speaking this indicates that |
|
We ran into the same issue, so we had started exhaustively testing our builds to try an establish a trend. We were successful in semi-reliably reproducing the crash within 5 attempts of uninstalling, re-installing and launching the same application build. We had recently updated If there's any additional information someone from Firebase needs to look into this, please let me know. |
|
We are seeing thousands of crashes on our latest app version due to Heap Corruption and we can't figure why as the logs are pretty unusable. We updated our app from 6.33 to 6.34 (6.33 was okay), here is a diff of our Podfile.lock if it helps: We do have Performance monitoring included, I'm going to remove it now if it helps and let you know, I just thought I'll leave this here as well if it helps debugging this issue. EDIT: Part of Performance monitoring is also ISASwizzler, MethodSwizzler and other libs (via screenshot) - it might be some of them as well.
|
|
Thank you for the provided details. We will continue investigation and post updates to the thread. |
|
@maksymmalyhin Hello. We are receiving same crashes from Alamofire after updating Firebase SDK to the last version. Would you suggest to downgrade to previous version and update the app before you fix the issue? |
|
Thanks for the report. In the most recent version of Firebase performance, we started using KVO to measure the completion of the network request. Not sure if this is conflicting with Alamofire. Can someone provide the following details?
We have already fixed a potential vulnerable code and this is expected to release soon. My guess is that this issue should be resolved with the fix. Will keep the thread posted. |
|
I would love to provide you with all the crashes we are seeing, but Firebase console doesn't allow us to share crashes as Fabric did, nor it has a way to export them. To answer:
If that helps, we also use PINRemoteImage for remote images loading, and we are seeing the crash there as well. Here is a txt file with 4 top crashes (we are talking about thousands of crashes on 1% rollout) - always only the first important thread, not the rest of threads. I hope that helps! |
|
@visumickey we are also using Alamofire |
|
We released new version of our app with Firebase 6.34.0 still but without Firebase Performance - no crashes so far, everything seems okay. That means the problem is in Firebase Performance and wasn't present in 6.33.0. :) |
|
@tspecht @paulb777 We're seeing this as well in our development CI builds on 7.0 as well as App Store version that released with 6.34.0 (pre-patch to Firebase Performance 3.3.2). We're hotfixing the App Store version to 6.34.0 post patch and will revert our dev code back from 7.0 till this is all resolved. |
|
@mthormann-dhi Since this is happening on the development CI builds, do you have any steps to reproduce this issue? Currently, we are working on all possibilities that could lead to such a crash and having a defined set of steps could expedite the fix greatly. Can you also provide details about the APIs you are making network request with? Eg. dataTaskWithURLRequest, [NSURLSession sessionWithDelegate] and likes. |
|
We can't get it to happen on any particular test. We run approx. 80 UI tests and it seems to trigger on different ones each time. Test order is randomized as well though. Doesn't seem to happen when we run just one or two tests though but more the whole suite. Most of our calls are done through Alamofire and/or AFNetworking. It's a mixed Objective-C/Swift project and we haven't been able to transition to just one. I do have a source branch that can pretty reliably duplicate things running interactively as well in Xcode. I'll see if I can fix the test order on Monday and nail it down if that helps. |
|
@mthormann-dhi That would be greatly helpful. In the meantime, we will continue to cleanup all possible scenarios where this issue might occur. Thanks for the information about Swift+ObjC app combined. We could add that to our mix of test cases. Can you share the version of AlamoFire and AFNetworking you are using? |
|
I, too, started seeing random crashes like the ones described above after upgrading to version 7. Not using Alamofire though. The project is 100% Swift with SwiftUI and runs only on iOS 14+. |
|
I am also seeing 1000's of crashes per day from my users with 7.0 (update went out 2 days ago). I have to revert my app back with an emergency update, and customers are pissed. The crashes happen randomly within the app and there are no set repro steps. Sometimes it happens when just opening views or pressing buttons that have no network calls associated with them. I am using Alamofire 5.3.0. Here's the trace:
|
|
Alamofire 5.2.2 Like the other comments we're seeing errors all over looks like related to KVO type stuff. Some stack traces as well.
|
|
I'll chime in here as well. I can confirm, zero crashes after downgrading to 6.34. See my pod install downgrade log: Analyzing dependencies I was able to do this by setting this in my pod file: Then running these commands: Then cleaning build folder in Xcode, letting it index, then building. |
|
Thank a lot for such useful stack traces. After a lot of reads, I think this crash is related to NSURLSession not compatible with KVO on the property 'state'. Recently Firebase Performance started observing on the 'state' property to identify the completion of the network request and that seems error prone (This was required because of iOS14). Reference to similar kind of crash: https://github.com/AFNetworking/AFNetworking/issues/1477, pinterest/PINRemoteImage#390 To mitigate this, we will remove the KVO based implementation with an alternate mechanism to stop these crashes from occurring. |
|
@maksymmalyhin which solution is best right now? |
|
@visumickey maybe you can recommend something in current situation. I have about 800 crashes after release new version in one day =) |
|
Two workarounds until the crash is addressed in Firebase 7.x:
|
|
@paulb777 thanks |
|
@petrykDima we have removed everything from the Firebase suite that was not 💯 necessary and will not be back any time soon ... |
|
We have released Firebase performance version 7.0.1 that removes the KVO implementation. Please update to the recent version of Firebase Performance to get away from the crashes users are experiencing. Thanks a lot of staying up and providing details information that enabled us to know about the issue with the Apple framework. |
|
@visumickey was a new |
|
@tspecht This emergency fix has only Firebase performance in it. You can set only the Firebase performance SDK's version to 7.0.1 to get past the issue. Other pods can continue to use the same version of Firebase you have. |
|
That is surprising. Based on the stack trace provided above, these issues were arising out of Firebase performance. If you are seeing this still, quite likely it is because of your other dependencies (most likely non-Firebase dependencies). |
|
One clarification is that we only released FirebasePerformance 7.0.1 for the CocoaPods distribution. Other distributions will include the fix in the upcoming 7.1.0 targeted to release next week. |
|
@paulb777 was this already pushed up to the Cocoapods remote? |
|
@tspecht Yes. The Firebase pod did not change versions. Only the FirebasePerformance pod. So either remove the version specifier or remove the slash - |
[REQUIRED] Step 1: Describe your environment
CocoaPodsOutput of
cat Podfile.lock | grep Firebase:[REQUIRED] Step 2: Describe the problem
After upgrading to Firebase
6.32.2or later from6.32.0, we get intermittent crashes in what seems to be the iOS internal networking stack. We are seeingSegmentation Fault: 11crashes in networking-related code within Alamofire, URLSession as well as Kingfisher, all without updating any of the SDKs. When downgrading to6.32.0again everything works fine, so it's related to Firebase.Steps to reproduce:
The issue happens rather randomly during what used to be normal usage of the app, but seems to be consistently related to networking code looking at the crash logs.
I attached two crash logs:
crash_report_1.txt
crash_report_2.txt
The text was updated successfully, but these errors were encountered: