-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Infinite loop causes app to crash after force quitting app #23
Comments
Hi @danniss10 This issue happens because OneSignal's swizzling implementation uses Instead, they should use a different approach where they change the implementation of This screenshot shows the final situation after OneSignal swizzles and Instabug swizzles This screenshot shows how it should look like References: |
An update, I have tested Instabug with OneSignal swizzling code, and I couldn't reproduce this issue. I have tested with the following project if you wanna give it a shot: InstabugOneSignal.zip |
Thanks for checking and for the helpful explanation @yousefhamza! Did more digging and was actually able to narrow it down to a commit where we integrated Google Firebase into our project. I don't understand why Firebase doesn't show up in the crash logs, but it looks like Firebase also does some swizzling which may interfere. We were able to get the crash to stop by adding this flag to our info.plist: FirebaseAppDelegateProxyEnabled=NO. Per this post on stack overflow, it disables the swizzling. For reference, we use firebase-ios-sdk 9.6.0 and import FirebaseRemoteConfig and FirebaseAnalytics |
Worth noting that OneSignal recently patched a similar crash in v3.11.2 OneSignal/OneSignal-iOS-SDK#1100 I was able to reproduce this crash in this version of the sample project: InstabugOneSignal.zip Explanation of the crash:
Which will end up in exactly the setup shown in the first screenshot here: #23 (comment) This scenario was happening in OneSignal via changing the app delegate; setting it to |
Current Issue@danniss10 Thanks for the extra detail on Firebase also being included and this detail:
Question@danniss10 Just to confirm what it takes to reproduce the issue?:
OneSignal Swizzling Details@yousefhamza I am one of the devs who work on the OneSignal iOS SDK. Great diagram showing the selector to implementation mapping of how swizzling is effecting things here! It's accurate from the OneSignal side of things. OneSignal does use method_exchangeImplementations which does change the Instabug + OneSignal SwizzlingIn your second test project (InstabugOneSignal.zip) you copied in some of the OneSignal logic but you're missing a key piece where OneSignal ensures it never swizzle the same class more than once: I think that is why in your first project (InstabugOneSignal.zip) you were not able to reproduce the bug since you were using the full OneSignal SDK. Thanks@yousefhamza Really appreciate the deep dive here on the swizzling investigation with OneSignal! |
Thanks for the kind words 🙏 About this
For the current bug, if the same sequence of events still happens, using method_setImplementation OneSignal implementation will be called, then Instabug implementaiton called, then OneSignal implementation called again, and that's it. This is far from ideal as I guess this may result in inaccurate data on your side, but arguably better than an infinite loop |
If anyone is still experiencing this, you might want to disable the Instabug crash report. I disabled it in my project because it also have Crashlytics for crash report so it's sort of convenient for us while we wait a definitive solution for this. |
Hi @henrique-eguchi If you still wish to use our crash reporting product, you can reach out to support to disable this feature until OneSignal can work out a solution with us 🙏 |
Steps to Reproduce the Problem
Actual Behavior
Crash occurs with some sort of infinite loop, see crash log below.
Instabug integration code
SDK Version
Instabug 11.4.1
iOS Version
Observed in iOS 16, 15, 14 crash reports
Device Model
Multiple
Crash log
The text was updated successfully, but these errors were encountered: