集群上多线程程序的分段故障定位

Question

在交互模式下运行一个简单的程序时，使用gdb来定位分段故障是非常简单的。但是考虑到我们有一个由pthread编写的多线程程序提交给一个集群节点(通过qsub命令)。所以我们没有交互式的操作。

我们如何定位分段故障？我正在寻找一种通用的方法，一个程序或测试工具。我不能提供一个可重现的例子，因为程序真的很大，并且在一些未知的情况下在集群上崩溃。

我需要在这样困难的情况下找到一个问题，因为程序可以在本地机器上使用任意数量的线程正确运行。

Answer 1

“正常”的方法是让环境生成一个核心文件并获取这些文件。如果这不是一个选项，那么您可能希望尝试为SIGSEGV安装一个信号处理程序，它至少会获得一个堆栈跟踪，并将其转储到某个地方。当然，这直接导致了问题"how to get a stack trace"，但这个问题在其他地方得到了回答。

最简单的方法可能是获得一个核心文件。假设您有一台可以读取核心文件的类似机器，您可以使用gdb program corefile调试生成核心文件corefile的程序program：您应该能够查看不同的线程、它们的数据(在某种程度上)等。如果您没有合适的机器，可能需要交叉编译与运行它的机器的硬件相匹配的gdb。

对于核心文件为空的说法，我有点困惑:您可以使用shell上的ulimit来设置核心文件的限制。如果核心的大小设置为零，它应该不会生成任何核心文件。产生一个空的似乎很奇怪。但是，如果您不能更改程序的限制，那么您可能需要安装一个信号处理程序，并从违规线程中转储堆栈跟踪。

考虑到这一点，假设您可以在相应的机器上运行调试器，那么您可以将程序置于信号处理程序中休眠，并使用调试器附加到它。您将确定进程ID (例如，使用ps -elf | grep program)，然后使用

gdb program pid

不过，我不确定如何从程序内部让程序进入睡眠状态(可能会安装用于SIGSEGV的SIGSTOP处理程序...)。

也就是说，我假设您尝试过在本地计算机上运行您的程序...？有些问题比需要在每个节点上运行多个线程的分布式系统更基本。显然，这不是上述方法的替代品。