[Re-opened Bug]: Rash of ANRs coming from OneSignal SDK #2230
Comments
|
I recall looking into some recent One Signal PRs around the time I originally opened #2176 , and I remember seeing someone discouraging the developer from using kotlin coroutines, and instead recommending they use Threads instead. If this is still the case, I suspect this is single-handedly the culprit. Coroutines don't block threads, and should be used instead of manually instantiating Threads. FWIW OneSignal is single-handedly putting our app past the bad-behavior ANR threshold on Google Play. Please take this issue seriously. |
|
@isles1217 Thanks for opening this issue. The stack traces you listed run on a background thread, could you share the main thread parts of the ANR? What the main thread is waiting on is key since an ANR only happens if the main thread is waiting for more than 5 seconds. If main thread is waiting on something from OneSignal then OneSignal could be the cause of the ANR, otherwise background threads shown in the ANR normally aren't the cause of it. |
|
I'm not sure how to best answer here, as I'm not sure how to surmise which segment of these OneSignal operations are happening on the main thread vs which ones aren't. According to Firebase, the main thread is getting blocked here, potentially because of a lock on an ArrayList/list? Is there a getOptAnyProperty: 
initializeFromJson: 
|
|
@isles1217 Yes this is what we are looking for! Could you share both those full stack traces as text?
|
|
Sure thing! getOptAnyProperty: runnable: blocked: |
|
initializeFromJson: runnable: blocked: |
|
Hello @isles1217, from these two lines, it seems the code is running on version 5.1.18 or earlier. com.onesignal.common.modeling.Model.initializeFromJson(Model.kt:98) It's possible that the reason you are still encountering this ANR is because many users are still using an older version of your app that runs on OneSignal SDK 5.1.18 or earlier. Could you filter the ANRs by your app version and show us the result? #2230 (comment) This looks like a deadlock to me. I will try to find the root cause of it and get back to you. Thank you for providing all the info! |
Hmm... I'm seeing those ANR on our newest releases, and we've had production releases on versions >= 5.1.20 since September. Let me take a look at my dependency tree in case another library is forcing an old version. |
|
I've confirmed that we're building with 5.1.25, and the stack traces passed along in my previous comments were from devices running our newest release, with 5.1.15. |
|
Any update on this? we're hoping to get this fixed and out before the holiday if at all possible. |
|
We have identified the problem and are actively working on a fix. I will keep you updated as soon as it is available. |
|
@jdonlan @isles1217 |
|
Thank you @jinliu9508 ! I've been observing this in the wild for the last week or so, and we're seeing our ANRs go down by about 50%, so THANK YOU! There's one particular stack trace that's still producing a lot of ANRs, so I opened a new issue to track that particular flow: #2236 |
What happened?
Reopened Issue (#2176)
Based on the ANR analytics we're getting from Firebase Crashlytics, 18 of our top 25 ANRs are being attributed to OneSignal. This is putting our application in danger of crossing the "good-behavior" ANR threshold. Please don't dismiss this as something you can't reproduce (as I'm seeing in several other ANR-related open issues). I suspect there is some kind of systemic pattern of handling long-running or asynchronous operations in a way that's likely impacting the apps that use your SDK.
In the last 90 days, One Signal has gotten attributed to over 1k different ANRs (this is just counting our top 25 ANR sources).
Steps to reproduce?
What did you expect to happen?
I would expect that this SDK would handle async and long running operations without causing ANRs.
OneSignal Android SDK version
5.1.25
Android version
15, 14, 13, 12, 11
Specific Android models
Relevant log output
Method calls that are being attributed to One Signal ANRs (in order of most occurring to least): com.onesignal.common.modeling.Model.initializeFromJson (6 different permutations of this) com.onesignal.common.modeling.Model.initializeFromJson(Model.kt:98) at com.onesignal.core.internal.operations.impl.OperationModelStore.create(OperationModelStore.kt:68) at com.onesignal.core.internal.operations.impl.OperationModelStore.create(OperationModelStore.kt:30) at com.onesignal.common.modeling.ModelStore.load(ModelStore.kt:175) at com.onesignal.core.internal.operations.impl.OperationModelStore.loadOperations(OperationModelStore.kt) at com.onesignal.core.internal.operations.impl.OperationRepo.loadSavedOperations$com_onesignal_core(OperationRepo.kt:418) at com.onesignal.core.internal.operations.impl.OperationRepo$start$1.invokeSuspend(OperationRepo.kt:100) com.onesignal.common.modeling.Model.getOptAnyProperty (8 different permutations of this) com.onesignal.common.modeling.ModelStore.load (3 different permutations of this) at java.util.Collections$SynchronizedMap.get(Collections.java:2738) at com.onesignal.common.modeling.Model.getOptAnyProperty(Model.kt:648) at com.onesignal.common.modeling.Model.getOptStringProperty(Model.kt:565) at com.onesignal.common.modeling.Model.getStringProperty(Model.kt:491) at com.onesignal.common.modeling.Model.getStringProperty$default(Model.kt:488) at com.onesignal.common.modeling.Model.getId(Model.kt:59) at com.onesignal.common.modeling.ModelStore.load(ModelStore.kt:184) at com.onesignal.core.internal.operations.impl.OperationModelStore.loadOperations(OperationModelStore.kt) at com.onesignal.core.internal.operations.impl.OperationRepo.loadSavedOperations$com_onesignal_core(OperationRepo.kt:418) at com.onesignal.core.internal.operations.impl.OperationRepo$start$1.invokeSuspend(OperationRepo.kt:100) com.onesignal.common.modeling.Model.getStringProperty at com.onesignal.common.modeling.Model.getStringProperty(Model.kt) at com.onesignal.common.modeling.Model.getStringProperty$default(Model.kt) at com.onesignal.common.modeling.Model.getId(Model.kt) at com.onesignal.common.modeling.ModelStore.load(ModelStore.kt) at com.onesignal.core.internal.operations.impl.OperationModelStore.loadOperations(OperationModelStore.kt) at com.onesignal.core.internal.operations.impl.OperationRepo.loadSavedOperations$com_onesignal_core(OperationRepo.kt) at com.onesignal.core.internal.operations.impl.OperationRepo$start$1.invokeSuspend(OperationRepo.kt)Code of Conduct
The text was updated successfully, but these errors were encountered: