GDB 无法显示堆栈并显示“#1 0x0000000000000000 in ?? ()”答案

【问题标题】：GDB cannot show the stack and shows "#1 0x0000000000000000 in ?? ()"GDB 无法显示堆栈并显示“#1 0x0000000000000000 in ?? ()”
【发布时间】：2011-07-28 16:53:20
【问题描述】：

我有一个多线程 C++ 程序，在极少数情况下会出现死锁。这个问题很难重现，我只能在远程机器上重现它。我想用来解决这个问题的方法是

运行程序
等待死锁
向其发送中止信号以生成核心转储
将转储复制回我的本地计算机
使用 gdb 进行调试

我在远程机器上没有 gdb，无法在上面安装任何东西。问题是当我调试核心转储（从远程机器上的死锁或正常运行的进程获得）时，大多数线程的回溯只显示：

(gdb) BT #0 pthread_cond_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261 #1 0x0000000000000000 在 ?? ()

我正在使用使用“-g -O1”选项编译的静态链接二进制文件。当我在本地机器上中止相同二进制文件的进程时，gdb 可以从核心转储中提取整个堆栈并且不存在这样的问题（但是我无法重现死锁）。我的远程机器是 SLES，我的本地机器是 ubuntu。

有什么想法吗？

编辑：

找到其他人遇到同样的问题，但仍然没有解决方案： http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 （我没有使用 google coredumper，但似乎 google coredumper 失败并出现同样的错误，这表明问题可能出在 SLES 11）

【问题讨论】：

标签： c++ linux gdb dump backtrace

【解决方案1】：

请注意，您也可以使用 gcore 创建核心文件而无需中止。您是否尝试过在远程主机上运行 pstack（假设它已安装）以查看是否可以通过这种方式获得回溯？

否则，如果您的应用程序使用的共享对象在本地主机和远程主机上不同，gdb 将无法正确匹配内存偏移量，并且回溯可能会变得混乱。如果您能够将所有相关的.so 文件从远程主机复制到本地某个地方，我相信您可以指示 gdb 读取它们而不是通常安装的版本。

编辑：尝试在您的构建机器上运行 pstack，看看它是否可以拾取堆栈。

【讨论】：

pstack 和 gcore 未安装。我正在静态链接二进制文件（使用-static），并且只有一个二进制文件我复制到远程机器并运行（没有共享库）
你确定二进制文件是完全静态的吗？我猜它与 libc.so 相关联。 ldd 的二进制输出是什么？
是的。 libc 版本在本地和远程机器上不兼容，我不得不用 -static 编译它 ldd 二进制的输出是“不是动态可执行文件”
@matt ，在 gdb 中，帮助 gcore 打印：“使用已调试进程的当前状态保存核心文件。”所以我想只有在远程机器上运行它才有意义。但问题是我在远程机器上没有 gdb。如果我有它，我可以在 gdb 下运行程序。

【解决方案2】：

你的 glibc 的年龄是多少？你可能错过了这个：

commit ad2be8527ac0f19f129fc4519d823cbe48239c78
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sun Apr 13 08:36:19 2003 +0000

    Update.

        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Add unwind info.
        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: Likewise.
        * sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.

【讨论】：

没有。 GCC 是一种新的（2009 年）。我的本地机器是内核 2.6.31 的 Ubuntu 9.10。
GCC 与它无关，内核也没有。 glibc 需要足够新。
这个提交是在 2003 年完成的。我的 GCC、glibc、内核和其他东西的版权归 2009 年所有。所以我猜他们包括这个提交。但是， ldd --version 显示版本 2.10.1