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