googlearchive/firebase-jobdispatcher-android

Deadlock in v0.8.5

dtuttle opened this issue · 5 comments

dtuttle commented

My code is making an API call to schedule a job (from a background worker thread) while the process' Main thread is handling a message for Firebase. The problem is that the two threads are locking the same objects in a different order :-(

The background thread scheduling a job locks 0x0b0a4414 then is blocked waiting on 0x0f9544bd. The main thread handling messages locks 0x0f9544bd then is blocked waiting on 0x0b0a4414.

Today, 9:11 AM on app version 60000021
LGE LG K20 Plus (lv517), Android 7.0
Report 1 of 3

The "main" (tid=1), "Thread-12" (tid=7) threads are in a deadlock.

"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x7444f598 self=0xa5f04400
| sysTid=15179 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0xa8d69534
| state=S schedstat=( 0 0 0 ) utm=6 stm=9 core=3 HZ=100
| stack=0xbe581000-0xbe583000 stackSize=8MB
| held mutexes=
at com.firebase.jobdispatcher.ExecutionDelegator.onJobFinishedMessage (ExecutionDelegator.java:140)

  • waiting to lock <0x0b0a4414> (a android.support.v4.util.SimpleArrayMap) held by thread 7
    at com.firebase.jobdispatcher.ExecutionDelegator.access$000 (ExecutionDelegator.java:36)
    at com.firebase.jobdispatcher.ExecutionDelegator$1.jobFinished (ExecutionDelegator.java:73)
    at com.firebase.jobdispatcher.JobService$JobCallback.sendResult (JobService.java:296)
    at com.firebase.jobdispatcher.JobService$2.run (JobService.java:168)
  • locked <0x0f9544bd> (a android.support.v4.util.SimpleArrayMap)
    at android.os.Handler.handleCallback (Handler.java:751)
    at android.os.Handler.dispatchMessage (Handler.java:95)
    at android.os.Looper.loop (Looper.java:154)
    at android.app.ActivityThread.main (ActivityThread.java:6316)
    at java.lang.reflect.Method.invoke! (Native method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:872)
    at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:762)

"Thread-12" prio=5 tid=7 Blocked
| group="main" sCount=1 dsCount=0 obj=0x22d91ee0 self=0xa5f04e00
| sysTid=16207 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x8c5f7920
| state=S schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100
| stack=0x8c4f5000-0x8c4f7000 stackSize=1038KB
| held mutexes=
at com.firebase.jobdispatcher.JobService.stop (JobService.java:183)

  • waiting to lock <0x0f9544bd> (a android.support.v4.util.SimpleArrayMap) held by thread 1
    at com.firebase.jobdispatcher.JobService$1.stop (JobService.java:114)
    at com.firebase.jobdispatcher.JobServiceConnection.stopJob (JobServiceConnection.java:123)
  • locked <0x09f4f226> (a com.firebase.jobdispatcher.JobServiceConnection)
    at com.firebase.jobdispatcher.JobServiceConnection.onStop (JobServiceConnection.java:110)
  • locked <0x09f4f226> (a com.firebase.jobdispatcher.JobServiceConnection)
    at com.firebase.jobdispatcher.ExecutionDelegator.stopJob (ExecutionDelegator.java:130)
  • locked <0x0b0a4414> (a android.support.v4.util.SimpleArrayMap)
    at com.firebase.jobdispatcher.GooglePlayReceiver.onSchedule (GooglePlayReceiver.java:303)
  • locked <0x0ed66fb9> (a android.support.v4.util.SimpleArrayMap)
    at com.firebase.jobdispatcher.GooglePlayDriver.schedule (GooglePlayDriver.java:87)
    at com.firebase.jobdispatcher.FirebaseJobDispatcher.schedule (FirebaseJobDispatcher.java:85)
    at com.firebase.jobdispatcher.FirebaseJobDispatcher.mustSchedule (FirebaseJobDispatcher.java:122)
    at com.devicescape.connectsdk.Bootstrap.scheduleDeviceIdentifiersJob (Bootstrap.java:1248)
    at com.devicescape.connectsdk.Bootstrap.access$900 (Bootstrap.java:49)
    at com.devicescape.connectsdk.Bootstrap$1.run (Bootstrap.java:1444)
    at java.lang.Thread.run (Thread.java:761)
cooliceman commented

Had the same problem, after my app version that integrated job dispatcher released, ANRs are raising because of this ANR.
any solution?

Fishfield commented

We have exactly the same ANR in our Apps

Qubitium commented

Until this is fixed by better locking code, you can sidestep the bugs by executing any relevant stopJob codes on the main/UI thread and you should see the ANRs rates drop like a rock.

Fishfield commented

Did anyone try v.0.8.6 and check if this issue is fixed?

toddshansen commented

please verify this is still occuring in v0.8.6 as there were additional fixes there.