libimagepipeline.so crashes

[zxz1990]

Description

We are developing a TV app for playing videos. In the video playing activity, some pictures are shown on the screen. For some videos, crash happens when the pictures are shown. This happens only in one device. So we do not know this is whether fresco's bug or OS's bug. Could some one analyse the log?
This is the java stack trace:
Crash thread java stack trace:
at com.facebook.imagepipeline.nativecode.Bitmaps.nativeCopyBitmap(Native Method)
at com.facebook.imagepipeline.nativecode.Bitmaps.copyBitmap(EDU:74)
at com.facebook.imagepipeline.request.a.b(EDU:121)
at com.facebook.imagepipeline.request.a.a(EDU:88)
at com.facebook.imagepipeline.request.a.process(EDU:65)
at com.facebook.imagepipeline.producers.ag$a.b(EDU:252)
at com.facebook.imagepipeline.producers.ag$a.c(EDU:220)
at com.facebook.imagepipeline.producers.ag$a.a(EDU:78)
at com.facebook.imagepipeline.producers.ag$a$2.run(EDU:178)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at com.facebook.imagepipeline.core.h$1.run(EDU:43)
at java.lang.Thread.run(Thread.java:841)

This is the native stack trace:
backtrace:
#00 pc 000221ba /system/lib/libc.so (__memcpy_base_aligned+61)
#1 pc 00024f39 /data/app-lib/com.cibn.tv.edu-2/libimagepipeline.so
#2 pc 0001f0e4 /system/lib/libvmkid_lemur.so
#3 pc 00085350 /system/lib/libvmkid_lemur.so (vInvokeNativeFast+296)
#4 pc 00028050 /system/lib/libvmkid_lemur.so
#5 pc 0008203c /system/lib/libvmkid_lemur.so (vInterpret+148)
#6 pc 0008c8a0 /system/lib/libvmkid_lemur.so (vCallMethod+832)
#7 pc 000bd1ec /system/lib/libvmkid_lemur.so
#8 pc 0000d228 /system/lib/libc.so (__thread_entry+72)
#9 pc 0000d3c0 /system/lib/libc.so (pthread_create+240)

This is the attached log.
fresco_crash.txt

Reproduction

[FILL THIS OUT: How can we reproduce the bug? Provide URLs to relevant images if possible, or a sample project.]

Solution

[OPTIONAL: Do you know what needs to be done to address this issue? Ideally, provide a pull request which fixes this issue.]

Additional Information

• Fresco version: [We have only tested with 1.3.0 and 1.5.0. Both of them have crashes.]
• Platform version: [ro.build.version.release]: [2.1.4-R-20151114.0102]
  [ro.build.version.sdk]: [19]

[lambdapioneer]

Thanks @zxz1990 for the issue. Can you provide us with the device details? From a first look this looks like it might be an issue with ashmem.

[zxz1990]

@lambdapioneer
getprop with grep "build" or "version"：

[ro.build.date]: [Mon Aug 24 16:52:24 CST 2015]
[ro.build.description]: [rk3188-user 4.4.2 KOT49H eng.hepeng.20150824.165001 tes
t-keys]
[ro.build.display.id]: [KOT49H test-keys]
[ro.build.fingerprint]: [rockchip/rk3188/rk3188:4.4.2/KOT49H/eng.hepeng.20150824
.165001:user/test-keys]
[ro.build.host]: [ubuntu]
[ro.build.id]: [KOT49H]
[ro.build.product]: [rk3188]
[ro.build.tags]: [test-keys]
[ro.build.type]: [user]
[ro.build.user]: [hepeng]
ro.build.version.codename: [REL]
ro.build.version.incremental: [eng.hepeng.20150824.165001]
ro.build.version.release: [2.1.4-R-20151114.0102]
ro.build.version.sdk: [19]

[ro.rksdk.version]: [RK30_ANDROID$(PLATFORM_VERSION)-SDK-v1.00.00 ]
[ro.tvos_codebase.version]: [2.1.0]
[ro.vendor.sw.version]: [RK3188_R-BOX_ANDROID4.4.2-SDK]
[ro.yunos.version.platform]: [3]
[ro.yunos.version.release]: [3.1.1-R-20160620.2000]
[ro.yunos.version.sdk]: [2]
[sys.gmali.version]: [7X_1_7]
[sys.settings_global_version]: [1]
[sys.settings_system_version]: [29]

[lambdapioneer]

This mostly only has information about the Rockchip RK3188 which is built into a variety of devices. Can you post the full getprop output as an attachment? Also, is this the device a set-top box or a tablet?

[zxz1990]

@lambdapioneer
This is a set-top box. And here is the getprop file:
getprop.txt

[lambdapioneer]

Hm, there's not much chance that I'll be able to reproduce this. Maybe when you can give me the unobfuscated stack trace, I might be able to point in some general direction. Otherwise, it would be on you to debug on the device (most likely the easiest is using logging calls in the C++ code).

You can try to change the code in ImagePipelineFactor#buildPlatformDecoder to always return the ArtDecoder. With that you should be able to exclude ashmem issues. If it indeed fixes your issue, we can talk about adding an option to disable ashmem as a configuration parameter.

CC @kirwan

[zxz1990]

This is an ashmem issue. We have evaded this crash by resizing the image to a small size with assembled url. Thanks for your assistance. @lambdapioneer

[oprisnik]

Great to see that you've resolved the issue.