在交互模式下运行简单程序时，使用gdb来定位分段错误非常简单。但是考虑我们有一个多线程程序 - 由pthread编写 - 提交给集群节点（通过qsub命令）。所以我们没有互动操作。
我们如何找到分段错误？我正在寻找一般方法，程序或测试工具。我不能提供一个可重现的例子，因为程序非常大并且在某些未知情况下会在群集上崩溃。
我需要在如此困难的情况下找到问题，因为程序在具有任意数量线程的本地计算机上正确运行。
答案 0 :(得分：4)
“正常”方法是让环境生成核心文件并获取它们。如果这不是一个选项，您可能想尝试为SIGSEGV安装信号处理程序，该处理程序至少获得某处转储的堆栈跟踪。当然，这会立即导致问题"how to get a stack trace"，但在其他地方也可以回答。
最简单的方法可能是获取核心文件。假设您有一台可以读取核心文件的类似机器，您可以使用gdb program corefile调试生成核心文件program的程序corefile：您应该能够查看不同的线程，它们的数据（在某种程度上）等。如果你没有合适的机器，可能需要交叉编译gdb匹配运行它的机器的硬件。
我对核心文件为空的说法感到有点困惑：您可以在shell上使用ulimit设置核心文件的限制。如果核心的大小设置为零，则不应生成任何核心文件。制作一个空的看起来很奇怪。但是，如果您无法更改程序的限制，则可能需要安装信号处理程序并从违规线程中转出堆栈跟踪。
考虑到这一点，您可以将程序置于信号处理程序中并使用调试器连接到它，假设您可以在相应的计算机上运行调试器。您将确定进程ID（使用例如ps -elf | grep program），然后使用
gdb program pid
我不确定如何让程序在程序中进入睡眠状态（可能为SIGSTOP安装SIGSEGV的处理程序...）。
那就是说，我假设您尝试在本地计算机上运行程序......？有些问题比需要在每个节点上运行的许多线程的分布式系统更为基础。显然，这不是上述方法的替代品。