Deadlock in v0.8.5

[dtuttle]

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]

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

[Fishfield]

We have exactly the same ANR in our Apps

[Qubitium]

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]

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

[toddshansen]

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