当我查看gdb中的backtrace时，我的应用程序有时会主要在malloc（）和malloc_consolidate（）中进行段错误。
我确认机器有足够的可用内存，甚至没有开始交换。我检查了ulimits的数据分段和最大内存大小，两者都设置为'无限'。我还在valgrind下运行了应用程序，但没有发现任何内存错误。
现在我没有想到还有什么可能导致这些段错误。有任何想法吗 ？
更新：由于我没有找到valgrind（或ptrcheck）的任何内容，可能是因为另一个应用程序正在破坏libc的内存结构，还是每个进程都有一个单独的结构？
来自http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking：
在使用malloc，realloc和free时检查和防范错误的另一种可能性是设置环境变量MALLOC_CHECK_。当设置MALLOC_CHECK_时，使用一种特殊（效率较低）的实现，该实现旨在容忍简单错误，例如使用相同参数进行双重调用，或者单个字节超出（逐个错误）。但是，并非所有此类错误都可以得到保护，并且可能导致内存泄漏。如果MALLOC_CHECK_设置为0，则会自动忽略任何检测到的堆损坏;如果设置为1，则在stderr上打印诊断;如果设置为2，则立即调用abort。这可能很有用，因为否则崩溃可能会在很晚之后发生，因此很难找到导致问题的真正原因。
最有可能的是，你正在摧毁堆 - 也就是说，你写的超出了你分配的一块内存的限制，而这正在覆盖malloc()用来管理堆的数据结构。这会导致malloc()访问无效的地址，并且您的应用程序崩溃。
耗尽内存不会导致malloc()崩溃 - 它只会返回NULL。如果您没有检查NULL，那可能会导致您的代码崩溃，但崩溃站点不会在malloc()中。
Valgrind没有报告任何错误，这有点奇怪 - 但是默认的“Memcheck”工具可能会遗漏一些错误。尝试使用"Ptrcheck" tool运行Valgrid。