NPE in SystemJobService [110564377]

Fixed

Bug

Status Update

No update yet.

Description

ma...@gmail.com

created issue #1

Jun 22, 2018 10:55AM

Component used: WorkManager
Version used: android.arch.work:work-runtime:1.0.0-alpha03
Devices/Android versions reproduced on: any

Stacktrace:
Caused by: java.lang.NullPointerException:
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:52)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3267)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1641)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:163)
at android.app.ActivityThread.main (ActivityThread.java:6379)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:904)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:794)

Description:
Hi,

Yes, I know its a duplicate of

https://issuetracker.google.com/issues/109894190, but it crashing our app a lot even given we are properly initializing your library.
We released first version of our app with WorkManager with alpha02 library and without any explicit calls to WorkManager.initialize(...) and received a lot of NPEs in our tracker for all the places with WorkManager.getInstance() calls in our code and internally in the library. We don't have multiple processes so I was sure you default initialization with empty ContentProvider should work. But looks like its not always working! (maybe it is not always working on devices based on modified Android forks?) I can't reproduce it manually, but I have a lot of submitted crashes.
Well, we added WorkManager.initialize(this, new Configuration.Builder().build()); inside our Application.onCreate() before calling super.onCreate(); and it indeed helped. We had no such exceptions on the next release.
But for the next release after it we updated library version to alpha03 and it started crashing a lot again. Even as we still have WorkManager.initialize(...) inside Application.onCreate(). Guys, issues like this are making adapting your library into real applications quite complicated, please consider reworking of the library initialization to make it more predictable.
I see that mostly it is crashing on Xiaomi devices, attaching screenshot with devices list.

Screen Shot 2018-06-22 at 11.49.13.png

152 KB

View

Download

Comments

su...@google.com <su...@google.com> #2Jun 22, 2018 04:31PM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

ct...@google.com <ct...@google.com> #3Jun 22, 2018 08:58PM

yea i'll take it.

ma...@gmail.com <ma...@gmail.com> #4Jun 25, 2018 01:29PM

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

su...@google.com <su...@google.com> #5Jun 25, 2018 03:59PM

just emitting same live data reproduces the issue.

@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}

ma...@gmail.com <ma...@gmail.com> #6Jun 25, 2018 04:03PM

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

ct...@google.com <ct...@google.com> #7Jun 27, 2018 05:25PM

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

su...@google.com <su...@google.com> Jul 2, 2018 10:10PM

Assigned to su...@google.com.

su...@google.com <su...@google.com> #8Jul 3, 2018 04:43PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019

Fix coroutine livedata race condition

This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.

We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)

Bug: 140249349
Test: BuildLiveDataTest#raceTest_*

Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40

M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt

https://android-review.googlesource.com/1112186

https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

ma...@gmail.com <ma...@gmail.com> #9Jul 3, 2018 07:04PM

We didn't specify this flag in manifest which means its enabled.

But how can it be crashing for so many users right after update? And why on Xiaomi mostly?

What do you think about the difference with Android-Job library? maybe it would be a good decision to initialize with current context in SystemJobService instead of crashing if no init yet called? What I previously wrote about it:
"Because of this issue we currently migrated our app to Evernote's Android-Job and I can say it is not crashing like this. I don't know did they do it accidentally or not but according to the sources they are not relaying on mandatory execution of InitContentProvider in their PlatformJobService or PlatformGcmService, they are calling JobManager.create(context) - analog or init(), not JobManager.instance(). Please check usages of JobManager.create(Context context) there

https://github.com/evernote/android-job. So it will work in their implementation even if the ordering of execution of broadcasts, services is broken."

su...@google.com <su...@google.com> #10Jul 3, 2018 07:10PM

It's still possible the Xiaomi device has a bug or non-standard behavior, as per earlier in the thread.

We cannot change to Evernote's implementation - they can freely try to create their singleton at any point because their configuration object is modifiable at runtime. Ours is not, and we think that's the correct decision. For example, we would not want to be able to change the Executor at runtime - that leads to a bunch of problems that aren't easy to reason about for us and the developer.

ma...@gmail.com <ma...@gmail.com> #11Jul 3, 2018 07:20PM

I really hope it will not be crashing after your changes, but if it still would I think you anyway will have to investigate and find a way how to handle it.
I mean once you will publish stable version and Android-Job developers would deprecate their library then way more developers could face it. And unfortunately Xiaomi is very popular device manufacturer.

yo...@gmail.com <yo...@gmail.com> #12Dec 13, 2022 08:17AM

Good morning please I won't this to update imedetill thanks