MALLOC_CHECK是不是多线程的？

Question

我正在开发一个多线程的C应用程序。最近我们观察到一些内存损坏(非常罕见)。以确定我们使用-lmcheck链接进行了测试。但是在我们了解到-lmcheck不是线程安全的之后。然后我们开始使用MALLOC_CHECK=3进行测试。这里我有一个未解决的疑问，即-lmcheck和MALLOC_CHECK=3的行为是否相同？MALLOC_CHECK=3线程是否安全？如果有人回答这个问题，这对我很有帮助..我试着用valgrind，电栅栏，但没有用。

Answer 1

根据GNU关于堆一致性检查的文章，mcheck被定义为MT-Unsafe。

中止函数: int mcheck (

(* mcheck_status int)(枚举状态))

初步：|MT-不安全的竞争:mcheck const:malloc_hooks |AS-不安全的损坏|AC-不安全的损坏

在上述安全上下文中调用MT-Unsafe、AS-Unsafe、AC-Unsafe函数是不安全的。在这样的上下文中调用它们会调用未定义的行为。

那么，使用MALLOC_CHECK_和使用‘-lmcheck’链接有什么区别呢？

MALLOC_CHECK_与‘-lmcheck’无关。添加‘-lmcheck’是为了向后兼容。MALLOC_CHECK_和‘-lmcheck’应该会发现相同的错误--但是使用MALLOC_CHECK_你不需要重新编译你的应用程序。

设置MALLOC_CHECK_ :

如果MALLOC_CHECK_设置为0(零)，则内存管理函数是最容错的，并且不会给出警告。如果我们被另一个不方便修复的内存bug阻止，它可能会很有用；它可能允许我们使用其他工具来追查另一个内存bug。如果您运行的代码可以在另一个系统上运行，但不能在Linux上运行，那么它可能也很有用。它可以提供一个快速的解决方法，允许代码在您有机会解决错误之前暂时正常工作。

如果MALLOC_CHECK_设置为1(1)，当发现问题时，内存管理函数会打印出标准错误的警告消息。如果我们没有意识到任何问题，并且只想在存在任何问题时得到通知，这是很有用的。

如果MALLOC_CHECK_设置为2(2)，当发现问题时，内存管理函数调用abort()。这在调试器或启动应用程序或守护进程的shell中最有用。它允许在内存管理功能发现错误时立即获得回溯，提供最接近错误发生点的信息。如果内核是由内存损坏引起的，我们就有更多关于内存分配的信息。这对于故障排除和确定应用程序覆盖内存地址的位置/应用程序更好。

设置1和2可以通过将MALLOC_CHECK_设置为3(3)来组合。这将启用打印输出标准错误(1)的警告消息，并在发现问题(2)时调用abort()。

欲了解更多信息，请通过此链接更好地了解：Heap Consistency Checking

Answer 2

由于您可以在不链接外部库的情况下使用MALLOC_CHECK_ (注意尾随下划线)方法，因此似乎可以合理地得出结论，它使用了与libmcheck不同的实现。在任何情况下，这两个都是GNU扩展，作为备选文档记录。

我想您真正想知道的是，使用MALLOC_CHECK_是否会破坏动态内存分配的线程安全性。Glibc指定它的malloc()实现是线程安全的(例如，参见https://stackoverflow.com/a/27047048/2402272)，这确实是POSIX所要求的。可以想象，它的线程安全性被MALLOC_CHECK_的非零值破坏了，但这似乎不太可能，我也找不到这样的文档。