-
Notifications
You must be signed in to change notification settings - Fork 371
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]: Model.getStringProperty$default crash due to NullPointerException #1839
Comments
Hi @fanwgwg thank you for your patience here! We are still attempting to reproduce this crash. Is there any additional information you might be able to share about when you experience this? Appreciate it! |
@jennantilla I don't have a consistent way to reproduce it, as I've only encountered at a chance like 2 out of 50. What my app does is that on every activity resume, we refresh OneSignal by doing
However, now that our app is released, we're also seeing this crash encountered by users and reported by crashlytics. Looking at the logs, they all happen at very early stage of app startup. |
Hi, I'm observing same issue in production. SDK version : [5.0.0, 5.99.99]
|
I'm also encountering the same crash, One Signal version 5.0.3. Stack trace:
|
Thank you all for your patience, unfortunately we are struggling to reproduce this on our end. I suspect a race condition during initialization, but I can't identify it looking through the code. If you are able to capture any logs beyond the stack trace (preferably with It might also help to understand where |
Have you ruled out that this isn't a proguard/obfuscation issue? That's the smell I'm getting from this. |
If it's not a proguard/obfuscation problem, the simplest way to guard against initialization race conditions is to wrap relevant member variables in |
We haven't ruled out proguard or obfuscation as the issue, but from the stack trace and how it appears to be non-deterministic makes me feel it's tied to how we save and load state across app lifecycles. @isles1217 if you could provide a more complete log showing the initialization prior to the stack trace, or provided more context in how OneSignal is initialized within your app, that would be tremendously helpful. Thanks for the insights! |
@brismithers see this comment for initialization logic: #1880 (comment) |
@isles1217 thanks for that! I wonder if your two issues are linked, if initWithContext is being driven so much it might drive some funky concurrency issues. Note I have PR #1903 which synchronizes initialization, and we also released v5.0.4 which added synchronization to the very area your stack trace is surfacing (#1876). I'm curious if these resolve what you are seeing in this issue. |
This has happened again in 5.0.4
|
Happens also in the Flutter lib 5.0.4. This is causing crashes specifically on Android 13. Please give us some visibility on how you will tackle this problem as it is a critical bug ! |
thank you for the feedback, we haven't been able to reproduce the issue on our side so we are primarily looking through code in an attempt to understand the issue. If you are able to provide a simple reproduction that will most definitely be helpful! |
I believe this is the same as issue #1995 and a fix for this is now available in OneSignal-Android-SDK 5.1.6 |
What happened?
Sometimes at app start, the app would randomly crash (saw 2 times out of ~50 attempts) at app open.
Crash:
Steps to reproduce?
What did you expect to happen?
App should not crash
OneSignal Android SDK version
5.0.1
Android version
13
Specific Android models
No response
Relevant log output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: