malloc() 和 malloc_consolidate() 中的段错误

2021-12-14 00:00:00 debugging malloc segmentation-fault c++

当我查看 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.

相关文章