Fatal signal 11 (SIGSEGV), code 2(SEGV_ACCERR), fault addr 解决方法
crash的log如下所示:
--------- beginning of crash
C000A02 03-06 05:06:11.503 506 506 F libc : Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x72a3d4d000 in tid 506 (secure_element@), pid 506 (secure_element@)
结论:出现SIGSEGV,是进程执行了一个无效的内存引用。
如何分析:内存错误发生后如何排查,尤其是 Fatal signal 11 (SIGSEGV)这个错误,报出来之后程序就会崩溃,定位还不好定位,如何定位到所出问题的函数或者代码行?分析 crash 的堆栈信息,通过地址定位源文件中出错的函数或具体行数(addr2line)
例如: 从log中可以看出发生crash
的栈的位置在这里: C000891 03-06 05:49:53.485 868 868 F DEBUG : backtrace:
C000892 03-06 05:49:53.485 868 868 F DEBUG : #00 pc 0000000000007ecc /vendor/lib64/libise_sprd_v3.0.so (ise_restore_backup_data_cmd(char const*, int)+268) (BuildId: a10304087685a0777dd57aa7de6a850b)
C00086B 03-06 05:49:53.475 868 868 F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7dfa3ee000
C00086C 03-06 05:49:53.475 868 868 F DEBUG : x0 000000000000000a x1 0000007dfa3f0ce5 x2 0000000000101002 x3 0000000000000000
C00086D 03-06 05:49:53.475 868 868 F DEBUG : x4 0000007fd234b3d0 x5 0000000000000010 x6 0000007dfbca1000 x7 0000000000000da0
C00086E 03-06 05:49:53.475 868 868 F DEBUG : x8 00000000000103f0 x9 00000000000223f0 x10 00000000000103f1 x11 0000000000006300
C00086F 03-06 05:49:53.475 868 868 F DEBUG : x12 0000007fd234b4f0 x13 0000000000000018 x14 001298bdfbd7ca80 x15 0000263dd04e4f72
C000870 03-06 05:49:53.475 868 868 F DEBUG : x16 0000007dfa3fa2e8 x17 0000007dfa5e8680 x18 0000007dfaf12000 x19 b400007dfa3ad040
C000871 03-06 05:49:53.475 868 868 F DEBUG : x20 000000000000000a x21 0000007dfa3f0ce5 x22 0000000000000000 x23 0000007dfa3fc4cc
C000872 03-06 05:49:53.475 868 868 F DEBUG : x24 0000007dfab3d000 x25 495345434f534d5a x26 0000000000000000 x27 0000000000000000
C000873 03-06 05:49:53.475 868 868 F DEBUG : x28 0000000000000000 x29 0000007fd234bc60
C000874 03-06 05:49:53.475 868 868 F DEBUG : lr 0000007dfa3f6e74 sp 0000007fd234bad0 pc 0000007dfa3f6ecc pst 0000000080001000
C000891 03-06 05:49:53.485 868 868 F DEBUG : backtrace:
C000892 03-06 05:49:53.485 868 868 F DEBUG : #00 pc 0000000000007ecc /vendor/lib64/libise_sprd_v3.0.so (ise_restore_backup_data_cmd(char const*, int)+268) (BuildId: a10304087685a0777dd57aa7de6a850b)
C000893 03-06 05:49:53.485 868 868 F DEBUG : #01 pc 0000000000006298 /vendor/lib64/libise_sprd_v3.0.so (ise_deploy_entry(int, bool)+1464) (BuildId: a10304087685a0777dd57aa7de6a850b)
C000894 03-06 05:49:53.485 868 868 F DEBUG : #02 pc 0000000000005c70 /vendor/lib64/libise_sprd_v3.0.so (SprdIseInit()+1772) (BuildId: a10304087685a0777dd57aa7de6a850b)
C000895 03-06 05:49:53.485 868 868 F DEBUG : #03 pc 0000000000003814 /vendor/bin/hw/vendor.sprd.hardware.secure_element@1.2-service (main+344) (BuildId: 7c13cc392671c2aa1f72f8273ea6369a)
C000896 03-06 05:49:53.485 868 868 F DEBUG : #04 pc 000000000004973c /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+108) (BuildId: 9d83dbbfa799e05a6f4331271a2387cd)
M000897 03-06 05:49:53.486 836 836 I gatekeeperd: Starting gatekeeperd...
解决方法:我的这个问题是由于数组的类型定义为u32,超出了分配的内存,导致的内存泄漏,改为u8或者扩大内存,就解决了。