Native ANR when decoding bitmap

[Bodo1981]

Describe the bug
We have a very big app with a lot of background threads. The codebase is mixed Java / Kotlin and the Layout Framework too (View / Compose). That´s why we use your library for image loading. Unfortunately we get a lot of ANR when trying to decode bitmaps. Especially on the new Google Pixel 7(a) Pro Devices. But sometimes on others too. This ANR seems only to happen, when webviews (e.g. Ads) and imageloading happens on the same screen. If we disable webviews OR imageloading everything is fine. I know it sounds weird but this really happens.

We find a workaround which seems to work. If i set ImageLoader.decoderDispatchers(Dispatchers.Main.Immediate) it works much better and at the moment we don´t get this ANR.

To Reproduce
Very fast scroll a recyclerview in a screen with webviews and other views with images and the default decoderDispatchers. Unfortunatelly I can´t provide a sample because I can not reproduce it with a sample. And I can´t share this app because I am not allowed to. But maybe this information helps you finding the bug. If you have any question I will definitly try to answer you and help you finding this weird bug.

Logs/Screenshots
I am not allowed to share this.

Version
I am using the version 2.4.0

[Bodo1981]

Unfortunately the crash still happens with this ImageLoader.decoderDispatchers(Dispatchers.Main.Immediate). Not as often as before but it is definitly not fixed.
But I found something interesting in the stacktrace.

Maybe this can help you. In this stacktrace there are a few calls to your sdk.

runtime.cc:682] "DefaultDispatcher-worker-12" prio=5 tid=73 Blocked
runtime.cc:682]   | group="" sCount=1 ucsCount=0 flags=1 obj=0x17f04078 self=0xb40000733aa14f40
runtime.cc:682]   | sysTid=9643 nice=0 cgrp=system sched=0/0 handle=0x7113124cb0
runtime.cc:682]   | state=S schedstat=( 483406455 32751709 606 ) utm=44 stm=3 core=3 HZ=100
runtime.cc:682]   | stack=0x7113021000-0x7113023000 stackSize=1039KB
runtime.cc:682]   | held mutexes=
runtime.cc:682]   native: #00 pc 000000000004f65c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: dc4001c2ef2dfc23467040797a96840c)
runtime.cc:682]   native: #01 pc 00000000003a8b44  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+140) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #02 pc 00000000003be8e8  /apex/com.android.art/lib64/libart.so (void art::Monitor::Lock<(art::LockReason)1>(art::Thread*)+8168) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #04 pc 0000000000458224  /apex/com.android.art/lib64/libart.so (art_quick_lock_object_no_inline+52) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #05 pc 000000000020170c  /apex/com.android.art/lib64/libart.so (nterp_op_monitor_enter+12) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #06 pc 00000000002d2318  [anon:dalvik-classes34.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes34.dex] (coil.disk.DiskLruCache.get)
runtime.cc:682]   native: #07 pc 000000000020a254  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #08 pc 00000000002d396c  [anon:dalvik-classes34.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes34.dex] (coil.disk.RealDiskCache.openSnapshot+12)
runtime.cc:682]   native: #09 pc 000000000020b074  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #10 pc 00000000002d53f2  [anon:dalvik-classes34.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes34.dex] (coil.fetch.HttpUriFetcher.readFromDiskCache+54)
runtime.cc:682]   native: #11 pc 00000000021b5e68  /memfd:jit-cache (deleted) (offset 2000000) (coil.fetch.HttpUriFetcher.fetch+824)
runtime.cc:682]   native: #12 pc 00000000021e11a8  /memfd:jit-cache (deleted) (offset 2000000) (coil.intercept.EngineInterceptor.fetch+1784)
runtime.cc:682]   native: #13 pc 00000000020c75f8  /memfd:jit-cache (deleted) (offset 2000000) (coil.intercept.EngineInterceptor.execute+3000)
runtime.cc:682]   native: #14 pc 000000000020a9d8  /apex/com.android.art/lib64/libart.so (nterp_helper+5848) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #15 pc 00000000002d6fac  [anon:dalvik-classes34.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes34.dex] (coil.intercept.EngineInterceptor.access$execute)
runtime.cc:682]   native: #16 pc 00000000021fae54  /memfd:jit-cache (deleted) (offset 2000000) (coil.intercept.EngineInterceptor$intercept$2.invokeSuspend+404)
runtime.cc:682]   native: #17 pc 00000000020b9fcc  /memfd:jit-cache (deleted) (offset 2000000) (kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith+316)
runtime.cc:682]   native: #18 pc 00000000020201a4  /memfd:jit-cache (deleted) (offset 2000000) (kotlinx.coroutines.DispatchedTask.run+2004)
runtime.cc:682]   native: #19 pc 000000000020b0d4  /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #20 pc 00000000000dbef2  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.internal.LimitedDispatcher$Worker.run+10)
runtime.cc:682]   native: #21 pc 000000000020b074  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #22 pc 00000000000e3ac2  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.scheduling.TaskImpl.run+6)
runtime.cc:682]   native: #23 pc 000000000020a254  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #24 pc 00000000000e2b8e  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely+2)
runtime.cc:682]   native: #25 pc 000000000020a254  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #26 pc 00000000000e176a  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask+34)
runtime.cc:682]   native: #27 pc 000000000020a254  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #28 pc 00000000000e1898  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker+56)
runtime.cc:682]   native: #29 pc 000000000020a254  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4bf4747707ca903605931dd6b3d0480c)
runtime.cc:682]   native: #30 pc 00000000000e1848  [anon:dalvik-classes38.dex extracted in memory from /data/app/~~2FoP0I2wrpzFyqMwmN3gHg==/***-VpcnR9EfYSUeBiXuqvyBBw==/base.apk!classes38.dex] (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run)```

[colinrtwhite]

What API levels does this occur on? Is there a subset of devices that this occurs on?

[Bodo1981]

@colinrtwhite It happens mainly (99%) on Pixel 7, Pixel 7a and Pixel 7 Pro Devices. So the API is fixed to 33. I tested some other Image Loading libraries (e.g. Glide). And the issue does not appear here. So it seams to be a really strange bug in the coil library.

If i can try some things to give you more information please let me know. we definitly love your library and don´t want to change to another one.

[colinrtwhite]

@Bodo1981 It looks like the ANR is occurring inside the DiskCache: coil.disk.DiskLruCache.get. If you disable the disk cache does that resolve the ANR? Also is the ANR noticeable when scrolling?

Unfortunately it's tough for me to figure out the issue without a sample that reproduces it.

[Bodo1981]

@colinrtwhite The crash still exists if i remove the DiskCache. But I was able to create a sample where you can reproduce it:
https://github.com/Bodo1981/CoilPixel7ProCrash

You can checkout this sample and when you open it on a Pixel 7 device (e.g. i tried it on Pixel 7 Pro) and you scroll through the list of images and webviews you get the crash. it does not always crash immediatelly but it definitly crashes. you should also not scroll to fast so that every image gets loaded.

it would be great if you can check it out and tell me if you can also reproduce the crash

[colinrtwhite]

@Bodo1981 Thanks for the repro. Unfortunately I don't have access to a Pixel 7, but once I get access to one I'll circle back and take a look.

[esnaultdev]

For visibility, the same issue has been reported in the Android Public Tracker (by the same author).
https://issuetracker.google.com/issues/291473026
It seems to be investigated there as well.

We also use Coil and WebViews in a RecyclerView and experience the same ANRs almost exclusively on Pixel 7 models (99% of the impacted devices).

[Bodo1981]

@esnaultdev Thx for jumping into this issue too.
Don´t get me wrong but it is good to hear that we are not the only one getting this ANRs on the new Pixel devices.
I hope this issue will be fixed soon.

I reased it here and at google because i recently talked to a google developer and he told me that it is better to have both sides (webview = google and coil = here) informed about the issue.

@colinrtwhite do you know when you have a chance to get hands on the new devices to check this or maybe can i help you directly?

PS: for all others please vote for this issue to get it fixed faster. thanks
https://issuetracker.google.com/issues/291473026

[Bodo1981]

Any progress on this issue. Let me know if i can help you with further informations. This task is really important for our company so it would be great if you can have a look at it.
thx

[colinrtwhite]

@Bodo1981 I haven't had a chance to look into this. If you're able to track down the issue locally, I'd accept a PR that patches the issue. Unfortunately this sounds like a device-specific issue, which are generally tough to work around. Have you tried disabling hardware bitmaps with ImageRequest.Builder.allowHardware(false)? That can sometimes resolve device-specific issues.

[gsrathoreniks]

@Bodo1981 Still facing the issue ?
I've tried using the repro you shared on Pixel 7 Pro API 33 but seems to work fine for me.