Fatal signal 11 (SIGSEGV), code 2(SEGV_ACCERR), fault addr 解决方法

最新推荐文章于 2025-04-10 17:36:37 发布

Haomione

最新推荐文章于 2025-04-10 17:36:37 发布

阅读量6.3k

点赞数 1

CC 4.0 BY-SA版权

文章标签： linux

本文链接：https://blog.csdn.net/Haomione/article/details/129737159

文章描述了一种特定的系统崩溃问题，由SIGSEGV信号引起，代码显示为SEGV_ACCERR。这通常意味着进程尝试访问无效的内存地址。通过分析crash的堆栈信息，特别是使用addr2line工具，可以定位到出问题的函数或代码行。文中提供的例子是一个由于数组定义类型不当导致的内存泄漏问题，通过调整类型或增加内存分配得以解决。

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

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或者扩大内存，就解决了。