-
Notifications
You must be signed in to change notification settings - Fork 264
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
Crash at app start with Kotlin/native; objc_getClassList causing initialize to fire before load on non-OneSignal #1042
Comments
For debugging purposes (and as a possible workaround): is it possible to disable swizzling and forward the calls manually to OneSignal? As a side effect that would allow to circumvent incompatibilities with other swizzling SDKs as well. |
@ubuntudroid Thanks for reporting and providing a full stack trace. Where the crash is happeningFrom the stack trace you provided it is crashing on this line of code in the OneSignal code base:
This code is used to detect what classes are available at runtime, before any swizzling is done. Why the crash is happeningThis class inspection is done very early on when the main app process starts. It seems may trigger a different initialization follow Kotlin is not expecting. This is only based on my understanding of Objective-C class loading and some of the method names I see towards the top stack trace such as The implementation used by OneSignal to list all loaded classes follows Apple's example so it should be the correct way to collect this: Disable SwizzlingYou can follow the details in PR #297 to test disabling OneSignal's Swizzling when running your app from Xcode to confirm the issue. However this isn't a replacement API to hook up the required events required for a number of the functionally to work, this will just help confirm the issue. Next steps - Example projectI see someone at Jetbrains tried to reproduce the issue without any luck. There was a follow up reply that the "Notification Service Extension" might be at play. I don't believe it would be as it will run the NSE on its own process and only fire when a pus notification is received. However if you can reproduce try removing the NSE to confirm this. Possible steps to reproduceI see you provided the following details the JetBrains ticket, we can attempt to reproduce as well, however a test project would help us get up to speed:
|
Thanks for the elaborate response @jkasten2 ! I'll try disabling swizzling and report back. Then I'll attempt to create a minimal test project if the guys at Jetbrains still can't reproduce. Shall we unify and continue this discussion over at the Jetbrains issue tracker? Might make things easier. When everything is said and done there we can post a summary over here. |
Hello guys! |
@artdfel Unfortunately I don't really know which part actually integrates the swizzling code. This is likely something @jkasten2 can easily answer. I'm stuck in a workshop right now, but will try find some time afterwards (in a few hours) for the test with disabling swizzling and replying to you over in the Kotlin issue tracker. Once more I would ask to move the discussion there (or stay here and pause it there, whatever you prefer) to streamline things. |
@jkasten2 just in case you are not following along over at the Kotlin issue tracker: I managed to create a sample project and I have invited you to that project and I've described my findings over there: https://youtrack.jetbrains.com/issue/KT-50982#focus=Comments-27-5727582.0-0 It is a Kotlin/native project, so to run it you need to set up a Kotlin/native environment on your machine. But from what I see I think it is a Kotlin/native issue, not a OneSignal one. The issue seems to be just triggered by the way OneSignal does swizzling (as opposed to e.g. Firebase Messaging where swizzling didn't cause such an issue for some reason). But I'm not proficient enough with iOS and swizzling in particular to know the difference. |
Hi!
By calling
(from https://stackoverflow.com/a/13326633/9444506). So this approach might affect not only Kotlin. In any case, we plan to workaround this on Kotlin side, by making the latter less sensitive to the |
@SvyatoslavScherbina Thanks for the research and providing those details! We will look into what we can also do on our end to prevent firing |
As suggested by @SvyatoslavScherbina over at the Kotlin issue tracker I've integrated OneSignal into our main project using SwiftPM and indeed it now works like a charm! I'm going to keep this open as integrating with CocoaPods would still be preferred by me and we can track the |
@jkasten2 do you have a rough timeline on when you can check out possible changes to the initialization/loading handling? I'm asking because while the SwiftPM solution works for building it breaks our export (likely a Kotlin/native issue), so it would be great if we could just integrate via Cocoapods. Given that the timeframe for the beta of the Kotlin version fixing this issue is May a fix on your end could land much quicker - that is, if you have the capacities of course. Otherwise I have to postpone migration to OneSignal until summer which would be a shame as everyone at our company was really looking forward to making heavy use of it during spring season. |
@jkasten2 Alternatively, can I just disable swizzling and implement the necessary function calls on my own? |
@ubuntudroid We don't have an option for this currently. The OneSignal change itself to move the swizzling logic from However if you would like we can attempt to make this change and do some light testing and provide it as a beta for you test further for your specific project setup. If this sounds good to you let us know if you will are integrating OneSignal with Cocoapods, SwiftPM, or something else. |
@jkasten2 Following up on this, we seem to be getting the exact same crash on native, swift project on iOS. Environment
Stacktrace
Given that the crash affects a significant number of users, any further input on this would be greatly appreciated |
@jkasten2 That sounds great! My goal is to integrate via CocoaPods, the SwiftPM solution was just an attempt to work around the issue. @spyrospassas Looking at your stacktrace I'm not sure this is exactly the same crash, but then again, I might not have enough iOS experience to confidently say this. However, it also does seem to happen during swizzling... 🤔 |
@jkasten2 do you have a rough ETA for such a beta? We are eager to adopt OneSignal, but unfortunately are blocked by this issue. |
Quick update from the Kotlin/native front: we managed to fix the SwiftPM issue and were able to export the archive properly. I'd still love to use OneSignal via CocoaPods with a statically linked shared library instead of sourcing OneSignal via SwiftPM and a dynamically linked shared library if that becomes possible at any point. But for now, I'm a happy dev. 😁 I'll keep this issue open for now @jkasten2 - feel free to close it if you decide to track the loading changes on another issue. |
Let me add, that to get reliable builds with OneSignal via SwiftPM I needed to also add OneSignal as a dependency to the Build Phases of OneSignalNotificationService extension. Otherwise builds would fail randomly on CI (and sometimes also in IDE) with |
Update: It turns out builds still weren't reliable, even with the above mentioned workaround implemented. What seems to work now: setting Build Order to |
@jkasten2 I'm reiterating on a very similar issue that we're getting with the native implementation of the SDK and seems related to swizzling: Environment
Steps to reproduce Stacktrace
The crash appears to be affecting a significant number of users (More than 2.000 devices have been affected in the last two weeks according to our data) |
We are looking at removing the call to |
This fix is now available in the OneSignal 3.11.2 release. |
Description:
Our app is based on Kotlin/native and after integration of the SDK as per the documentation we are seeing a crash right at app start likely caused by the swizzling done by the SDK and how that is handled by Kotlin/native.
I've also reported it over in the Kotlin/native issue tracker because it is more likely to be a problem caused by Kotlin/native, but you might be able to help them debug the problem, thus this issue. You can find the Kotlin/native issue report here: https://youtrack.jetbrains.com/issue/KT-50982
Environment
Steps to Reproduce Issue:
Please check my description here: https://youtrack.jetbrains.com/issue/KT-50982
Anything else:
Stacktrace:
The text was updated successfully, but these errors were encountered: