我有一个multithreadingC ++程序，在极less数情况下会死锁。 问题很难重现，我只能在远程机器上重现它。 我想用来解决这个问题的方法是
我在远程机器上没有gdb，无法安装任何东西。 问题是当我正在debugging核心转储（从远程机器上的死锁或正常运行的进程中获得）时，大多数线程的反向跟踪仅显示：
（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的。
任何想法？
编辑：
发现别人有同样的问题，但仍然没有解决scheme： http : //groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 （我不使用谷歌Coredumper，但它似乎像谷歌Coredumper失败同样的错误，这表明也许问题是与SLES 11）
请注意，您也可以使用gcore创建核心文件而不中止。 你有没有尝试在远程主机上运行pstack（假设已经安装）来查看是否能以这种方式获得回溯？
否则，如果您的应用程序使用的共享对象在您的本地主机和远程主机上不同，那么gdb将无法正确匹配内存偏移，并且回溯可能会全部混淆。 如果你能够将所有相关的.so文件从远程主机复制到本地某个地方，我相信你可以直接从它们读取gdb而不是正常安装的版本。
编辑：尝试在你的生成机器上运行pstack，看看它是否可以拿起一个堆栈。
你的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.