如果我重新启动 Asterisk，大约 10 个核心转储会出现在/tmp 目录中，所有这些都会出现相同的崩溃。执行ps -ef手动不会重现崩溃。
gdb 输出:
Core was generated by `ps -ef'.
Program terminated with signal 11, Segmentation fault.
#0 reset_global () at ps/global.c:362
362 look_up_our_self(&p);
(gdb)
反汇编:
0x0000000000403040 <+0>: push %rbp
0x0000000000403041 <+1>: mov $0xdeadbeef,%eax
0x0000000000403046 <+6>: push %rbx
0x0000000000403047 <+7>: sub $0x80028,%rsp
0x000000000040304e <+14>: mov 0x21147b(%rip),%rbx # 0x6144d0 <selection_list>
0x0000000000403055 <+21>: cmp %rax,%rbx
0x0000000000403058 <+24>: je 0x403084 <reset_global+68>
0x000000000040305a <+26>: test %rbx,%rbx
0x000000000040305d <+29>: jne 0x40306b <reset_global+43>
0x000000000040305f <+31>: jmp 0x403084 <reset_global+68>
0x0000000000403061 <+33>: nopl 0x0(%rax)
0x0000000000403068 <+40>: mov %rbp,%rbx
0x000000000040306b <+43>: mov 0x8(%rbx),%rdi
0x000000000040306f <+47>: mov (%rbx),%rbp
0x0000000000403072 <+50>: callq 0x4017e8 <free@plt>
0x0000000000403077 <+55>: mov %rbx,%rdi
0x000000000040307a <+58>: callq 0x4017e8 <free@plt>
0x000000000040307f <+63>: test %rbp,%rbp
0x0000000000403082 <+66>: jne 0x403068 <reset_global+40>
0x0000000000403084 <+68>: lea 0x80010(%rsp),%rbx
0x000000000040308c <+76>: mov $0x634680,%edi
0x0000000000403091 <+81>: movq $0x0,0x211434(%rip) # 0x6144d0 <selection_list>
=> 0x000000000040309c <+92>: callq 0x401908 <look_up_our_self@plt>
0x00000000004030a1 <+97>: xor %eax,%eax
0x00000000004030a3 <+99>: mov %rbx,%rdx
0x00000000004030a6 <+102>: mov $0x5413,%esi
0x00000000004030ab <+107>: mov $0x1,%edi
0x00000000004030b0 <+112>: callq 0x401698 <ioctl@plt>
0x00000000004030b5 <+117>: cmp $0xffffffffffffffff,%eax
0x00000000004030b8 <+120>: je 0x4032e0 <reset_global+672>
...
这是什么:0x0000000000403041 <+1>: mov $0xdeadbeef,%eax ？
信息寄存器:
(gdb) info registers
rax 0xdeadbeef 3735928559
rbx 0x7849d15d9e60 132258440519264
rcx 0x0 0
rdx 0x0 0
rsi 0x7849d15d9de0 132258440519136
rdi 0x634680 6506112
rbp 0x0 0x0
rsp 0x7849d1559e50 0x7849d1559e50
r8 0x0 0
r9 0xff3212ff2a1f09ff -57962958069757441
r10 0x8 8
r11 0x206 518
r12 0x2 2
r13 0x7849d15da0a8 132258440519848
r14 0x0 0
r15 0x0 0
rip 0x40309c 0x40309c <reset_global+92>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
系统信息:
3.14.32-xxxx-grs-ipv6-64 #7 SMP Wed Jan 27 18:05:09 CET 2016 x86_64 x86_64 x86_64 GNU/Linux
rpm -qa | grep glibc
glibc-2.12-1.166.el6_7.7.x86_64
glibc-debuginfo-common-2.12-1.166.el6_7.7.x86_64
glibc-headers-2.12-1.166.el6_7.7.x86_64
glibc-2.12-1.166.el6_7.7.i686
glibc-common-2.12-1.166.el6_7.7.x86_64
glibc-debuginfo-2.12-1.166.el6_7.7.x86_64
glibc-devel-2.12-1.166.el6_7.7.x86_64
我不知道如何从这里继续，尝试从头开始重新安装 Linux，但得到相同的结果。
最佳答案
=> 0x000000000040309c <+92>: callq 0x401908 <look_up_our_self@plt>
程序死在 CALL 上有点不寻常。 (或 PUSH )指令，每当发生这种情况时，几乎可以肯定会出现堆栈溢出。此外，
0x0000000000403047 <+7>: sub $0x80028,%rsp
这个函数需要半个 MiB 的堆栈，这也很不寻常，而且很大。看看剩下的反汇编，如果 JE在0x403058被采取，然后 CALL在0x40309c将是在大减量之后尝试将某些内容插入堆栈的第一条指令。
结论:Asterix执行的环境ps -ef有一个uimit -s设置得太小。
What is this:
0x0000000000403041 <+1>: mov $0xdeadbeef,%eax?
代码比较%RAX与 selection_list 。 0xdeadbeef显然是 sentinel value .
关于linux - ps -ef 在 Asterisk 重新启动期间崩溃，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35904715/