如果我重新启动Asterisk，在/ tmp目录中将出现大约10个核心转储，所有这些转储都有相同的崩溃。 手动执行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)
Disassmble：
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被采取，那么在0x40309c CALL将是在大递减之后尝试将某物推入堆栈的第一条指令。
结论：Asterix执行ps -ef的环境有一个uimit -s设置太小。
这是什么：
0x0000000000403041 <+1>: mov $0xdeadbeef,%eax？
代码将%RAX与selection_list进行比较。 0xdeadbeef显然是一个前哨值 。