Question

如果我重新启动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？

info register：

(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，但得到相同的结果。

Answer 1

=> 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设置得太小。

这是什么：0x0000000000403041 <+1>: mov $0xdeadbeef,%eax？

代码将%RAX与selection_list进行比较。 0xdeadbeef显然是sentinel value。

ps -ef在Asterisk重启期间崩溃

1 个答案: