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後，沒有再次出現該問題，這個問題纏了好幾天，巨坑，特此記錄。