signal 6 (SIGABRT), code -6 name: RenderThread问题记录

75 阅读 0 评论 50 点赞

我是靠谱客的博主无私水池，最近开发中收集的这篇文章主要介绍signal 6 (SIGABRT), code -6 name: RenderThread问题记录，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

关于signal 6 (SIGABRT), code -6 name: RenderThread异常的调试记录

开发项目中遇到了一个比较难受的异常，报错信息基本上都是指向地址比如：#452362之类的，看的很头疼，不知如何，排查了很久，终究找到有类似问题的帖子，特此记录解决方案

问题描述：
项目中使用到了USB摄像头，有个场景是使用USB摄像头进行拍照，刚开始测试的次数少，没有发现，后来现场反应拍照或者其他界面会出现奔溃的问题，通过远程日志没有看出来什么，刚开始以为USB底层库有问题，通过定位so库也没有发现问题存在。后来通过AndroidStudio自带的内存实时监控功能 profiler实际查看内存情况，发现每次操作打开摄像头内存会上涨15-25M左右，关闭后只降低一部分内存，也就是每次操作都会增加内存，慢慢的内存一直增大。后来本地调试看了下具体日志，如下：

I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
08-12 16:16:15.018 294-294/? I/DEBUG: Build fingerprint: ‘Android/slm753/slm753:5.1.1/LMY47V/Data.BU03121622:userdebug/release-keys’
08-12 16:16:15.019 294-294/? I/DEBUG: Revision: ‘0’
08-12 16:16:15.019 294-294/? I/DEBUG: ABI: ‘arm’
08-12 16:16:15.020 294-294/? I/DEBUG: pid: 12602, tid: 12685, name: RenderThread >>> com.decard.socialcarddischsystem_m200 <<<
08-12 16:16:15.020 294-294/? I/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
08-12 16:16:15.155 294-294/? I/DEBUG: Abort message: ‘requireSurface() called but no surface set!’
08-12 16:16:15.155 294-294/? I/DEBUG: r0 00000000 r1 0000318d r2 00000006 r3 00000000
08-12 16:16:15.155 294-294/? I/DEBUG: r4 e401bdd8 r5 00000006 r6 00000018 r7 0000010c
08-12 16:16:15.155 294-294/? I/DEBUG: r8 ab5364ec r9 e401bd28 sl e401bd20 fp ab536528
08-12 16:16:15.155 294-294/? I/DEBUG: ip 0000318d sp e401b878 lr f7496c2d pc f74bbef8 cpsr 600f0010
08-12 16:16:15.156 294-294/? I/DEBUG: backtrace:
08-12 16:16:15.156 294-294/? I/DEBUG: #00 pc 00038ef8 /system/lib/libc.so (tgkill+12)
08-12 16:16:15.156 294-294/? I/DEBUG: #01 pc 00013c29 /system/lib/libc.so (pthread_kill+52)
08-12 16:16:15.156 294-294/? I/DEBUG: #02 pc 00014847 /system/lib/libc.so (raise+10)
08-12 16:16:15.156 294-294/? I/DEBUG: #03 pc 00010fd5 /system/lib/libc.so (__libc_android_abort+36)
08-12 16:16:15.156 294-294/? I/DEBUG: #04 pc 0000f534 /system/lib/libc.so (abort+4)
08-12 16:16:15.157 294-294/? I/DEBUG: #05 pc 00007905 /system/lib/libcutils.so (__android_log_assert+88)
08-12 16:16:15.157 294-294/? I/DEBUG: #06 pc 0003a71f /system/lib/libhwui.so
08-12 16:16:15.157 294-294/? I/DEBUG: #07 pc 0003aa91 /system/lib/libhwui.so
08-12 16:16:15.157 294-294/? I/DEBUG: #08 pc 0003befd /system/lib/libhwui.so
08-12 16:16:15.157 294-294/? I/DEBUG: #09 pc 0003be21 /system/lib/libhwui.so
08-12 16:16:15.157 294-294/? I/DEBUG: #10 pc 0003c829 /system/lib/libhwui.so
08-12 16:16:15.157 294-294/? I/DEBUG: #11 pc 0003d19f /system/lib/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+66)
08-12 16:16:15.157 294-294/? I/DEBUG: #12 pc 0000ef55 /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+112)
08-12 16:16:15.157 294-294/? I/DEBUG: #13 pc 0005be91 /system/lib/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+72)
08-12 16:16:15.157 294-294/? I/DEBUG: #14 pc 0000eac5 /system/lib/libutils.so
08-12 16:16:15.158 294-294/? I/DEBUG: #15 pc 00013413 /system/lib/libc.so (_ZL15__pthread_startPv+30)
08-12 16:16:15.158 294-294/? I/DEBUG: #16 pc 0001133f /system/lib/libc.so (__start_thread+6)

。
大致原因是因为GPU过度了，系统底层的bug，主要是在界面切换之间传递数据导致的，而且每次都是在程序运行一段时间后出现，频率比较高，排除了是USB底层so库的问题。然后就看界面切换，在拍照界面主要携带了Serializable序列化的实体数据，后来百度发现Serializable会产生大量的临时变量，这样会导致系统频繁的GC，垃圾回收，而Parcelable则不会，所以替换成Parcelable后，没有再次出现该问题，这个问题缠了好几天，巨坑，特此记录。