我从多线程进程分段错误崩溃中获得了一个核心转储。在使用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构建的，没有任何优化，使用- 0。我们通常只使用不到一半的RAM (300- 400mb/1G)。实际上，我在不同的核心文件中也看到了这种模式的回溯(针对不同的错误转储)。使这种症状真正奇怪(不同于普通的堆栈损坏)的是，不止一个线程有这样的反向跟踪模式，帧#0、#1与这个完全相同，但#2、#3地址可能与这个不同。
看起来您可能在没有启用调试的情况下进行编译。
确保在编译时传入-g
此外，正如Joachim Pileborg在他的评论中提到的，重复的堆栈帧意味着您可能在某个地方损坏了堆栈。这通常是在数组结束后写入存储的帧指针的结果。
如果你想检查由于内存相关问题引起的分段错误，或者想检查内存泄漏，最好使用Valgrind，它给出了有关内存泄漏的所有信息。