"无法解释的"核心转储

Question

我一生中见过许多核心垃圾场,但这一次让我难过.

语境:

• 在AMD Barcelona CPU 集群上运行的多线程Linux/x86_64程序
• 崩溃的代码执行得很多
• 在负载下运行1000个程序实例(完全相同的优化二进制文件)每小时产生1-2次崩溃
• 崩溃发生在不同的机器上(但机器本身非常相同)
• 崩溃看起来都一样(相同的确切地址,相同的调用堆栈)

以下是崩溃的详细信息:

Program terminated with signal 11, Segmentation fault.
#0  0x00000000017bd9fd in Foo()
(gdb) x/i $pc
=> 0x17bd9fd <_Z3Foov+349>: rex.RB orb $0x8d,(%r15)

(gdb) x/6i $pc-12
0x17bd9f1 <_Z3Foov+337>:    mov    (%rbx),%eax
0x17bd9f3 <_Z3Foov+339>:    mov    %rbx,%rdi
0x17bd9f6 <_Z3Foov+342>:    callq  *0x70(%rax)
0x17bd9f9 <_Z3Foov+345>:    cmp    %eax,%r12d
0x17bd9fc <_Z3Foov+348>:    mov    %eax,-0x80(%rbp)
0x17bd9ff <_Z3Foov+351>:    jge    0x17bd97e <_Z3Foov+222>

您会注意到崩溃发生在指令中间0x17bd9fc,即从调用返回0x17bd9f6到虚函数之后.

当我检查虚拟表时,我发现它没有以任何方式损坏:

(gdb) x/a $rbx
0x2ab094951f80: 0x3f8c550 <_ZTI4Foo1+16>
(gdb) x/a 0x3f8c550+0x70
0x3f8c5c0 <_ZTI4Foo1+128>:  0x2d3d7b0 <_ZN4Foo13GetEv>

并且它指向这个微不足道的功能(正如通过查看源代码所预期的那样):

(gdb) disas 0x2d3d7b0
Dump of assembler code for function _ZN4Foo13GetEv:
   0x0000000002d3d7b0 <+0>: push   %rbp
   0x0000000002d3d7b1 <+1>: mov    0x70(%rdi),%eax
   0x0000000002d3d7b4 <+4>: mov    %rsp,%rbp
   0x0000000002d3d7b7 <+7>: leaveq 
   0x0000000002d3d7b8 <+8>: retq   
End of assembler dump.

此外,当我查看Foo1::Get()应该返回的返回地址时:

(gdb) x/a $rsp-8
0x2afa55602048: 0x17bd9f9 <_Z3Foov+345>

我看到它指向正确的指令,所以就好像在返回期间Foo1::Get(),一些gremlin出现并且增加%rip了4.

合理的解释？

Answer 1

因此,看起来不太可能,我们似乎遇到了真正的真正的CPU错误.

http://support.amd.com/us/Processor_TechDocs/41322_10h_Rev_Gd.pdf有错误#721:

721处理器可能会错误地更新堆栈指针

描述

Under a highly specific and detailed set of internal timing conditions,
the processor may incorrectly update the stack pointer after a long series
of push and/or near-call instructions, or a long series of pop 
and/or near-return instructions. The processor must be in 64-bit mode for
this erratum to occur.

对系统的潜在影响

The stack pointer value jumps by a value of approximately 1024, either in
the positive or negative direction.
This incorrect stack pointer causes unpredictable program or system behavior,
usually observed as a program exception or crash (for example, a #GP or #UD).

Answer 2

我曾经在指令中间看到过“非法操作码”崩溃。我在 Linux 端口上工作。长话短说，Linux 从指令指针中减去以重新启动系统调用，在我的情况下，这发生了两次（如果两个信号同时到达）。

所以这是一个可能的罪魁祸首：内核摆弄您的指令指针。您的情况可能还有其他原因。

请记住，有时处理器会将其正在处理的数据理解为指令，即使它不应该如此。所以处理器可能已经在 0x17bd9fa 处执行了“指令”，然后移动到 0x17bd9fd，然后生成了一个非法的操作码异常。（我只是编造了这个数字，但是使用反汇编器进行试验可以显示处理器可能“进入”指令流的位置。）

调试愉快！