分析堆栈损坏的核心转储

Question

我目前正在尝试调试我的 C++ 应用程序中的核心。客户报告了SEGFAULT具有以下线程列表的核心：

...Other threads go above here
  3 Thread 0xf73a2b70 (LWP 2120)  0x006fa430 in __kernel_vsyscall ()
  2 Thread 0x2291b70 (LWP 2212)  0x006fa430 in __kernel_vsyscall ()
* 1 Thread 0x218fb70 (LWP 2210)  0x00000000 in ?? ()

令我困惑的是崩溃的线程指向0x00000000. 如果我尝试检查回溯，我会得到：

Thread 1 (Thread 0x1eeeb70 (LWP 27156)):
#0  0x00000000 in ?? ()
#1  0x00281da7 in SomeClass1::_someKnownMethod1 (this=..., elem=...) at path_to_cpp_file:line_number
#2  0x0028484d in SomeClass2::_someKnownMethod2 (this=..., stream=..., stanza=...) at path_to_cpp_file:line_number
#3  0x002958b2 in SomeClass3::_someKnownMethod3 (this=..., stream=..., elem=...) at path_to_cpp_file:line_number

我对编辑表示歉意——这是保密协议的局限性。

显然，顶部框架是相当未知的。我的第一个猜测是PC寄存器被某些堆栈覆盖损坏了。

我已尝试通过提供与其中看到的相同的调用在本地部署中重现该问题，Frame #1但从未发生过崩溃。

众所周知，这些内核很难调试？但是有人对尝试什么有一些提示吗？

更新

   0x00281d8b <+171>:   mov    edx,DWORD PTR [ebp+0x8]
   0x00281d8e <+174>:   mov    ecx,DWORD PTR [ebp+0xc]
   0x00281d91 <+177>:   mov    eax,DWORD PTR [edx+0x8]
   0x00281d94 <+180>:   mov    edx,DWORD PTR [eax]
   0x00281d96 <+182>:   mov    DWORD PTR [esp+0x8],ecx
   0x00281d9a <+186>:   mov    ecx,DWORD PTR [ebp+0x8]
   0x00281d9d <+189>:   mov    DWORD PTR [esp],eax
   0x00281da0 <+192>:   mov    DWORD PTR [esp+0x4],ecx
   0x00281da4 <+196>:   call   DWORD PTR [edx+0x14]
=> 0x00281da7 <+199>:   mov    ebx,DWORD PTR [ebp-0xc]
   0x00281daa <+202>:   mov    esi,DWORD PTR [ebp-0x8]
   0x00281dad <+205>:   mov    edi,DWORD PTR [ebp-0x4]
   0x00281db0 <+208>:   mov    esp,ebp
   0x00281db2 <+210>:   pop    ebp
   0x00281db3 <+211>:   ret
   0x00281db4 <+212>:   lea    esi,[esi+eiz*1+0x0]

...应该是来自 的Frame #0，但从反汇编来看，这没有什么意义。就好像程序在从 返回时崩溃了Frame #1，但为什么我看到的是无效的Frame #0？或者这个框架拆卸部分属于一个功能onPacket？

更新#2：

(gdb) p/x $edx
$5 = 0x1deb664
(gdb) print _listener
$6 = (jax::MyClass &) @0xf6dbf6c4: {_vptr.MyClass= 0x1deb664}

Answer 1

扩展海特的评论，因为堆栈的其余部分看起来不错，我怀疑第 1 帧中出现问题；考虑以下（显然不正确的）程序，它会生成类似的堆栈跟踪：

int main() {
    void (*foo)() = 0;
    foo();

    return 0;
}

堆栈跟踪：

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000040056a in main ()