GDB不能显示堆栈并显示“＃1 0x0000000000000000 in ?? （）“。 [英] GDB cannot show the stack and shows "#1 0x0000000000000000 in ?? ()"

问题描述

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

I have a multi-threaded C++ program that deadlocks in some rare cases. The problem is hard to reproduce and I can only reproduce it in a remote machine. The method I want to use for solving this problem is

1. 运行程序


2. 等待死锁


3. 向其发送中止信号以生成核心转储


4. 将转储复制回我的本地计算机


5. 使用gdb调试它

1. run the program
2. wait for deadlock
3. send abort signal to it for generating core dump
4. copy the dump back to my local machine
5. use gdb to debug it

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

I do not have gdb on the remote machine and cannot install anything on it. The problem is when I am debugging the core dump (obtained from either a dead-locked or normally running process on the remote machine), the back-trace of most of the threads show only:

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

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

I am using a statically linked binary which is compiled with "-g -O1" options. When I abort a process of the same binary on my local machine, gdb can extract the entire stack from core dump and there is no such problem (I cannot reproduce the deadlock however). My remote machine is SLES and my local machine is ubuntu.

有什么想法吗？

：

找到具有相同问题但仍没有解决方案的其他人：
http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050
（我不是使用google coredumper，但似乎谷歌coredumper失败，同样的错误，这表明也许问题是SLES 11）

Found someone else with the same problem, but still with no solutions: http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 (I am not using google coredumper, but it seems like google coredumper fails with the same error, this suggests that perhaps the problem is with SLES 11)

推荐答案

p>注意，你也可以使用gcore来创建一个核心文件而不中止。你试过在远程主机上运行pstack（假设它已经安装），看看你是否可以这样得到一个backtrace？

Note that you can also use gcore to create a core file without aborting. Have you tried running pstack on the remote host (assuming it's installed) to see if you can get a backtrace that way?

否则，如果应用程序使用的共享对象在本地主机和远程主机上是不同的，gdb将无法正确匹配内存偏移，并且backtrace可能会得到所有的困惑。如果你能够将所有相关的 .so 文件从远程主机复制到本地的某个地方，我相信你可以直接从gdb读取，而不是正常安装的版本。

Otherwise, if the shared objects used by your application are different on your local host and remote host, gdb won't be able to match the memory offsets properly and the backtrace will probably get all confused. If you're able to copy all the relevant .so files from the remote host to some place locally I believe you can direct gdb to read from them instead of the normally installed versions.

编辑：尝试在你的构建机器上运行pstack，看看它是否可以拿起一个堆栈。

try running pstack on your build machine and see if it can pick up a stack.

这篇关于GDB不能显示堆栈并显示“＃1 0x0000000000000000 in ?? （）“。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！