C++ malloc() 和 malloc_consolidate() 中的段错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3100193/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Segfaults in malloc() and malloc_consolidate()
提问by Gene Vincent
My application segfaults sometimes and mainly in malloc() and malloc_consolidate() when I look at the backtrace in gdb.
当我查看 gdb 中的回溯时，我的应用程序段错误有时主要发生在 malloc() 和 malloc_consolidate() 中。
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.
我确认机器有足够的可用内存，它甚至没有开始交换。我检查了数据段的 ulimits 和最大内存大小，两者都设置为“无限制”。我还在 valgrind 下运行了该应用程序，但没有发现任何内存错误。
Now I'm out of ideas what else might be causing these segfaults. Any Ideas ?
现在我不知道还有什么可能导致这些段错误。有任何想法吗 ？
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 ?
更新：由于我没有找到任何与 valgrind（或 ptrcheck）有关的东西，是不是另一个应用程序正在破坏 libc 的内存结构，还是每个进程都有一个单独的结构？
回答by BillTorpey
From http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking:
从http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking：
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.
在 malloc、realloc 和 free 的使用中检查和防止错误的另一种可能性是设置环境变量 MALLOC_CHECK_。当设置 MALLOC_CHECK_ 时，将使用一种特殊的（效率较低的）实现，该实现旨在容忍简单的错误，例如使用相同参数对 free 的双重调用，或单个字节的溢出（逐一错误）。然而，并非所有此类错误都可以防止，并且可能导致内存泄漏。如果 MALLOC_CHECK_ 设置为 0，则任何检测到的堆损坏都会被静默忽略；如果设置为 1，则在 stderr 上打印诊断信息；如果设置为 2，则立即调用 abort。这可能很有用，因为否则崩溃可能会在很晚之后发生，并且很难找到问题的真正原因。
回答by Martin B
Most likely, you're trashing the heap -- i.e., you're writing beyond the limits of a piece of memory you allocated, and this is overwriting the data structures that malloc()uses to manage the heap. This causes malloc()to access an invalid address, and your application crashes.
最有可能的是，您正在破坏堆——即，您写入的内容超出了您分配的一块内存的限制，这将覆盖malloc()用于管理堆的数据结构。这会导致malloc()访问无效地址，并且您的应用程序崩溃。
Running out of memory would not cause malloc()to crash -- it would simply return NULL. That might cause your code to crash if you're not checking for NULL, but the crash site would not be in malloc().
内存不足不会导致malloc()崩溃——它只会返回NULL。如果您不检查NULL，这可能会导致您的代码崩溃，但崩溃站点不会在malloc().
It's slightly strange that Valgrind is not reporting any errors -- but there are some errors that the default "Memcheck" tool can miss. Try running Valgrid with the "Ptrcheck" toolinstead.
Valgrind 没有报告任何错误有点奇怪——但是有一些默认的“Memcheck”工具可能会错过的错误。尝试使用“Ptrcheck”工具运行 Valgrid 。
