malloc() 和 malloc_consolidate() 中的段错误
当我查看 gdb 中的回溯时，我的应用程序有时会出现段错误，主要是在 malloc() 和 malloc_consolidate() 中.
My application segfaults sometimes and mainly in malloc() and malloc_consolidate() when I look at the backtrace in gdb.
我确认机器有足够的可用内存，它甚至没有开始交换.我检查了数据段的 ulimits 和最大内存大小，两者都设置为无限制".我也在 valgrind 下运行该应用程序，没有发现任何内存错误.
I verified that the machine has enough memory available, it didn't even start swapping. I checked ulimits for data segement and max memory size and both are set to 'unlimited'. I also ran the application under valgrind and didn't find any memory errors.
现在我不知道还有什么可能导致这些段错误.有什么想法吗?
Now I'm out of ideas what else might be causing these segfaults. Any Ideas ?
更新:由于我没有找到任何与 valgrind(或 ptrcheck)有关的东西，是不是另一个应用程序正在破坏 libc 的内存结构，还是每个进程都有一个单独的结构?
Update: Since I'm not finding anything with valgrind (or ptrcheck), could it be that another application is trashing libc's memory structure or is there a separate structure for each process ?
推荐答案
来自 http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking:
检查和防范使用中的错误的另一种可能性malloc、realloc和free是设置环境变量MALLOC_CHECK_.当 MALLOC_CHECK_ 被设置时，一个特殊的(效率较低的)使用了旨在容忍简单的实现错误，例如使用相同参数两次调用 free，或单个字节的溢出(逐一错误).并非所有此类错误都可以但是，可能会导致内存泄漏.如果MALLOC_CHECK_ 设置为 0，任何检测到的堆损坏都是静默的忽略；如果设置为 1，则在 stderr 上打印诊断信息；如果设置为 2，立即调用 abort.这可能很有用，因为否则崩溃可能发生得更晚，问题的真正原因是然后很难追查.
Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
相关文章