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

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

  • 我在远程计算机上没有gdb,也无法在其上安装任何东西。
    问题是当我调试核心转储(从远程计算机上的死锁或正常运行的进程获得)时,大多数线程的回溯仅显示:

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

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

    任何想法?

    编辑:

    找到其他人遇到相同的问题,但仍然没有解决办法:
    http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050
    (我没有使用google coredumper,但似乎google coredumper失败并出现相同的错误,这表明问题可能出在SLES 11上)

    最佳答案

    请注意,您也可以使用gcore创建核心文件而不会中止。您是否尝试过在远程主机上运行pstack(假设已安装),以查看是否可以通过这种方式获得回溯?

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

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

    关于c++ - GDB无法显示堆栈并显示 "#1 0x0000000000000000 in ?? ()",我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/6862672/

    10-16 07:19