【发布时间】：2020-01-09 22:59:30
【问题描述】：
我有一个在 ARM 平台上运行的多线程程序。在其中一个线程中，我将调用 system() 来运行某些 shell 命令。 最近发现，system() fork 的子进程偶尔会以 SIGSEGV 结束。
strace 显示以以下消息终止的子进程。
1423872694.771573 set_robust_list(0xb5a90070, 12) = 0
1423872694.773834 rt_sigaction(SIGINT, {SIG_IGN, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
1423872694.774906 rt_sigaction(SIGQUIT, {SIG_IGN, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
1423872694.775973 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1423872694.776986 execve("/bin/sh", ["sh", "-c", "sync"], [/* 17 vars */]) = 0
1423872694.784928 brk(0) = 0xea000
1423872694.786133 uname({sys="Linux", node="localhost", ...}) = 0
1423872694.787440 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
1423872694.788602 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe} ---
1423872694.789370 +++ killed by SIGSEGV +++
我得到了coredump文件并用gdb对其进行了分析，结果如下。 在这种状态下似乎不会发生分段错误。你想告诉为什么触发 SIGSEGV，或者我在寻找 SIGSEGV 的原因时错过了什么？
Core was generated by `sh -c sync'.
Program terminated with signal 11, Segmentation fault.
#0 0x4d8f1008 in _dl_map_object (loader=0x4d912968, name=0xe1629 "libtinfo.so.5", type=<optimized out>, trace_mode=0, mode=0, nsid=0) at dl-load.c:2187
2187 dl-load.c: No such file or directory.
(gdb) bt
#0 0x4d8f1008 in _dl_map_object (loader=0x4d912968, name=0xe1629 "libtinfo.so.5", type=<optimized out>, trace_mode=0, mode=0, nsid=0) at dl-load.c:2187
#1 0x4d8f647c in openaux (a=0xbe89a99c) at dl-deps.c:64
#2 0x4d8f83cc in _dl_catch_error (objname=0x0, errstring=0x4d912880 <data.11735>, mallocedp=0xbe89a9b8, operate=0xbe89a9b4, args=0xbe89a99c) at dl-error.c:178
#3 0x4d8f6708 in _dl_map_object_deps (map=0x4d912968, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=0, open_mode=0) at dl-deps.c:257
#4 0x4d8ebbb4 in dl_main (phdr=<optimized out>, phnum=1301358928, user_entry=0x1, auxv=0x4d912050 <_rtld_global>) at rtld.c:1939
#5 0x4d8fede8 in _dl_sysdep_start (start_argptr=<optimized out>, dl_main=0x4d8fede8 <_dl_sysdep_start+572>) at ../elf/dl-sysdep.c:244
#6 0x4d8ea0b8 in _dl_start_final (arg=0xbe89bda0, info=<optimized out>) at rtld.c:431
#7 0x4d8ea3b8 in _dl_start (arg=0x0) at rtld.c:659
#8 0x4d8e8e30 in _start () from /opt/windriver/wrlinux/5.0-digital-spear320-newpuppy/sysroots/digital_spear320-wrs-linux-gnueabi/lib/ld-linux.so.3
Backtrace stopped: frame did not save the PC
(gdb) info registers
r0 0x0 0
r1 0xe 14
r2 0x0 0
r3 0x4d911f30 1301356336
r4 0xe1629 923177
r5 0x0 0
r6 0x4d912968 1301358952
r7 0x4d912b00 1301359360
r8 0x1 1
r9 0x1 1
r10 0x0 0
r11 0x0 0
r12 0xbe89a72c 3196692268
sp 0xbe89a4e8 0xbe89a4e8
lr 0x2 2
pc 0x4d8f1008 0x4d8f1008 <_dl_map_object+672>
cpsr 0x20000010 536870928
(gdb) disassemble
0x4d8f0fd8 <+624>: ldr r1, [sp, #36] ; 0x24
0x4d8f0fdc <+628>: add r3, pc, r12
0x4d8f0fe0 <+632>: add r12, sp, #572 ; 0x23c
0x4d8f0fe4 <+636>: str r12, [sp]
0x4d8f0fe8 <+640>: add r12, sp, #56 ; 0x38
0x4d8f0fec <+644>: stmib sp, {r12, lr}
0x4d8f0ff0 <+648>: mov lr, #2
0x4d8f0ff4 <+652>: add r12, sp, #580 ; 0x244
0x4d8f0ff8 <+656>: add r3, r3, #24
0x4d8f0ffc <+660>: str lr, [sp, #12]
0x4d8f1000 <+664>: mov r0, r4
0x4d8f1004 <+668>: add lr, r12, #3
=> 0x4d8f1008 <+672>: str lr, [sp, #16]
0x4d8f100c <+676>: bl 0x4d8ee9d0 <open_path>
0x4d8f1010 <+680>: cmn r0, #1
0x4d8f1014 <+684>: mov r1, r0
0x4d8f1018 <+688>: movne r3, #0
0x4d8f101c <+692>: moveq r3, #1
0x4d8f1020 <+696>: tst r3, r8
0x4d8f1024 <+700>: bne 0x4d8f119c <_dl_map_object+1076>
(gdb) x/64a 0xbe89a4e8 - 32
0xbe89a4c8: 0x0 0x0 0x0 0xe1629
0xbe89a4d8: 0x0 0x4d912968 0x0 0xe1629
0xbe89a4e8: 0xbe89a724 0xbe89a520 0x4d912968 0x2
0xbe89a4f8: 0x0 0x0 0x0 0x0
0xbe89a508: 0x0 0xe 0x4d912968 0x0
0xbe89a518: 0x1 0x1 0x0 0x0
0xbe89a528: 0x0 0x0 0x0 0x0
0xbe89a538: 0x0 0x0 0x0 0x0
0xbe89a548: 0x0 0x0 0x0 0x0
0xbe89a558: 0x0 0x0 0x0 0x0
0xbe89a568: 0x0 0x0 0x0 0x0
0xbe89a578: 0x0 0x0 0x0 0x0
0xbe89a588: 0x0 0x0 0x0 0x0
0xbe89a598: 0x0 0x0 0x0 0x0
0xbe89a5a8: 0x0 0x0 0x0 0x0
0xbe89a5b8: 0x0 0x0 0x0 0x0
(gdb) info threads
Id Target Id Frame
* 1 LWP 289 0x4d8f1008 in _dl_map_object (loader=0x4d912968, name=0xe1629 "libtinfo.so.5", type=<optimized out>, trace_mode=0, mode=0, nsid=0) at dl-load.c:2187
【问题讨论】：
-
您得到分段错误，因为代码中有错误。如果代码是你的，那么你可以debug it。否则，您必须尝试找到一个可以轻松复制问题的案例并将其报告给程序的作者或维护者。
-
而且根本不要使用
system()电话。这是 99.99% 的迹象表明代码完全错误。 -
请注意，崩溃发生的位置和实际根本原因所在的位置通常有所不同。以使用空指针调用
strlen为例，如果它崩溃，那么它会发生在strlen函数中，但问题本身并不存在。它实际上可能在调用堆栈中高了几个级别。 -
@PSkocik，你是对的，通过回溯，我可以确认它正在根据 LD_LIBRARY_PATH 的环境变量进行库加载。取消设置 LD_LIBRARY_PATH 后，我无法重现此错误。但是我找不到 LD_LIBRARY_PATH 与 SIGSEGV 的因果关系。恐怕不是根本原因。
-
@JL2210，不，只是一个基于 ARM 的嵌入式系统。
标签： c linux-kernel gdb embedded-linux glibc