我从多线程进程分段故障崩溃中获得了核心转储。在使用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地址可能与此不同。
答案 0 :(得分：1)
看起来您可能正在编译而未启用调试。
确保在编译时传递-g。
另外，正如Joachim Pileborg在评论中提到的那样，重复的堆栈框架意味着您可能在某处损坏了堆栈。这通常是通过将数组末尾写入存储的帧指针的结果。
答案 1 :(得分：0)
如果你想检查由于内存相关问题导致的分段错误，或者想要检查内存泄漏，而不是更好地使用 Valgrind ，它提供了有关内存泄漏的所有信息。