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

最新推荐文章于 2025-06-22 11:38:08 发布

sunshine_zs

最新推荐文章于 2025-06-22 11:38:08 发布

阅读量1w

点赞数 34

CC 4.0 BY-SA版权

分类专栏：问题处理文章标签： Bug 硬件加速序列化

本文链接：https://blog.youkuaiyun.com/baidu_29638129/article/details/99639410

问题处理专栏收录该内容

3 篇文章

订阅专栏

本文记录了一次在项目中遇到的SIGABRT异常调试过程，详细解析了异常的根本原因及解决方案，涉及到内存泄漏、GC机制及数据序列化选择。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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