我从多线程进程分段故障崩溃中获得了核心转储。在使用 GDB 检查核心文件时，我发现一些线程(不是全部)有这样的回溯:
Thread 4 (LWP 3344):
#0 0x405ced04 in select () from /lib/arm-linux-gnueabi/libc.so.6
#1 0x405cecf8 in select () from /lib/arm-linux-gnueabi/libc.so.6
#2 0x000007d0 in ?? ()
#3 0x000007d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
我检查了我们的源代码，发现那些线程最终调用了 select()。我想了解为什么/如何省略这些中间框架。
这种模式也发生在 read() 调用中。
知道这里发生了什么吗？恐怕这表明我们的 coredump 配置有问题，或者其他什么。预先感谢您的帮助!!
编辑:
感谢所有回复。我很抱歉我没有提供足够的信息。这里有更多:
可执行文件是使用编译器 -g 构建的，没有任何优化，使用 -O0。
我们一般只使用不到一半的 RAM 300-400 MB/1G。
实际上，我也在不同的核心文件中看到了这种模式回溯(为不同的故障转储)。
是什么让这个症状真正有线(不同于普通的堆栈损坏)是不止一个线程有这样的回溯模式，帧#0，#1 与这个完全相同，但#2 #3 地址可能与此不同。
最佳答案
看起来您可能在未启用调试的情况下进行编译。
确保在编译时传入-g。
此外，正如 Joachim Pileborg 在他的评论中提到的那样，重复的堆栈框架意味着您可能在某处损坏了堆栈。这通常是将数组末尾写入存储的帧指针的结果。
关于Linux 核心转储回溯丢失的帧，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25130916/