【问题标题】:SIGSEGV in RenderScript appRenderScript 应用程序中的 SIGSEGV
【发布时间】:2018-03-25 19:29:29
【问题描述】:

我在 Google Play 上发布了一个 Android 应用程序,该应用程序大部分是在 RenderScript 中实现的(本机,不使用支持库 API)。该应用程序有时似乎在 libCB.so 中崩溃。 Google Play 管理中心报告的崩溃率为 1.40%。

崩溃似乎发生在从 6.0 到 8.1(API 级别 23–27)的所有 Android 版本中。即使应用程序的 minSdkVersion 为 18(Android 4.3),我也没有收到旧版本的报告。各种制造商的各种设备似乎都受到了影响,无论是廉价的杂牌产品还是高端设备。

该应用使用 Camera 1 API 从实时预览视频 (setPreviewCallbackWithBuffer) 中捕获帧。 PreviewCallback 通过一系列处理该输入的 RenderScripts 发送帧数据。在两个阶段,处理后的数据也被发送到两个不同的TextureViews。如有需要,我可以提供更多详细信息。

我不确定是什么导致了问题,因为我无法在我自己的任何测试设备上本地重现它。

有谁知道这个问题的原因或是否有任何解决方法?

这是一个典型的回溯:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/land/land:6.0.1/MMB29M/V9.2.2.0.MALMIEK:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 17840, tid: 17862, name: JNISurfaceTextu >>> com.app.my <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x38
r0 00000000 r1 00000000 r2 00000002 r3 00000000
r4 00000000 r5 ef8e0a38 r6 00000002 r7 00000000
r8 ab06e808 r9 00000000 sl 00000000 fp ef8e0c30
ip e044d8f8 sp ef8e09f8 lr e03ac9b3 pc e03ac89c cpsr 800f0030

backtrace:
#00 pc 0003189c /system/vendor/lib/libCB.so (cl_mem_non_local_event_cache_state_transition+15)
#01 pc 000319af /system/vendor/lib/libCB.so (cl_mem_grant_access_to_device_internal+58)
#02 pc 00031ae5 /system/vendor/lib/libCB.so (cb_grant_access_to_device+84)
#03 pc 0000eb61 /system/vendor/lib/librs_adreno.so
#04 pc 0000683b /system/vendor/lib/librs_adreno.so
#05 pc 000068a1 /system/vendor/lib/librs_adreno.so
#06 pc 00007f33 /system/vendor/lib/librs_adreno.so
#07 pc 00009707 /system/vendor/lib/librs_adreno.so
#08 pc 00009ee5 /system/vendor/lib/librs_adreno.so
#09 pc 000088f5 /system/vendor/lib/librs_adreno.so (rsdVendorScriptInvokeForEach3+236)
#10 pc 00019bf9 /system/vendor/lib/libRSDriver_adreno.so (_Z29rsdVendorInvokeForEachWrapperPKN7android12renderscript7ContextEPNS0_6ScriptEjPPKNS0_10AllocationEjPS6_PKvjPK12RsScriptCall+84)
#11 pc 00019cfb /system/vendor/lib/libRSDriver_adreno.so (_Z27rsdScriptInvokeForEachMultiPKN7android12renderscript7ContextEPNS0_6ScriptEjPPKNS0_10AllocationEjPS6_PKvjPK12RsScriptCall+38)
#12 pc 0002ebf3 /system/lib/libRS.so (_ZN7android12renderscript7ScriptC10runForEachEPNS0_7ContextEjPPKNS0_10AllocationEjPS4_PKvjPK12RsScriptCall+294)
#13 pc 00033e41 /system/lib/libRS.so (_ZN7android12renderscript22rsp_ScriptForEachMultiEPNS0_7ContextEPKvj+48)
#14 pc 000311ff /system/lib/libRS.so (_ZN7android12renderscript8ThreadIO16playCoreCommandsEPNS0_7ContextEi+338)
#15 pc 00023d27 /system/lib/libRS.so (_ZN7android12renderscript7Context10threadProcEPv+646)
#16 pc 0004185b /system/lib/libc.so (_ZL15__pthread_startPv+30)
#17 pc 000192a5 /system/lib/libc.so (__start_thread+6)

【问题讨论】:

    标签: android renderscript android-renderscript


    【解决方案1】:

    嗯,我们在为 Android 编译的 opencv c++ 代码中遇到了类似的问题。

    我们的错误是设置了调用 jni 函数的计时器,然后忘记了清除它们。最终垃圾收集器无法跟踪导致内存泄漏的引用。因此,我们的应用程序通常会崩溃,除非它被用户杀死一整天,可能是一整天。

    您是否在代码中的任何位置设置了计时器?

    或者您是否正在跟踪调用 jni 函数的线程(如果它们中的任何一个存在)?

    如果您有兴趣,不妨查看一下:Timer::purge()

    【讨论】:

    • 嗯,我不确定,我不直接调用任何 jni 函数,它是 RenderScript 代码。工作完成后,我同时调用 RenderScript.destroy() 和 HandlerThread.quit()。但是您可能正在做某事,我没有想到可能的内存不足问题,也许“grant_access_to_device”误导了我。我将尝试在更长的时间内监控内存消耗并报告我的发现。
    • 好的,我运行了一些测试,它看起来不像是内存不足的问题。我反复启动和销毁活动,该过程仍然存在。虽然本机内存使用量最初上升,但它在 10 MB 左右达到稳定水平。 RenderScript 实例数为 1,Allocation 实例数为常数。如果我手动销毁()分配或等待终结器到它,这没有什么区别。
    • 是的,那么它不应该与引用和内存泄漏有关。您是说崩溃发生在 6.0 和 8.1 之间的版本上。没有崩溃
    • 我的意思是,最后它是一个分段错误,这表明本机代码正在尝试访问不存在的内存或未授予自身的内存空间。至少从我的角度来看,这似乎不是你的错,而是本机代码。对这些设备上的 libCB 版本有任何想法吗?也许他们在 5.0 之后升级了库版本或其他东西。这就是您在 上看不到崩溃的原因
    • 是的,6.0 及更高版本有数百个报告,而从 4.4 到 5.1 的报告没有一个。就像王淼说的那样,这很可能是高通驱动程序中的一个错误。
    【解决方案2】:

    崩溃主要与 libCB.so 相关吗?如果是这样,则可能是 Qualcomm RenderScript 驱动程序中的错误。我怀疑它只会影响某些 SOC。

    请在https://buganizer.corp.google.com/issues?q=componentid:192772 中提交错误,并附上重现此错误的潜在步骤。

    【讨论】:

    • 是的,崩溃都与 libCB.so 有关。具体在grant_access_to_device、mem_grant_access_to_device_internal和mem_non_local_event_cache_state_transition如上图。我不知道如何重现这个。
    • 那个 buganizer 页面要求我使用 @google.com 帐户登录。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-07-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多