debugging - glibc 的 MALLOC_CHECK_、M_CHECK_ACTION 和 mcheck 有什么区别？

Question

glibc 似乎有不止一种方法来做一些堆检查:

带有 M_CHECK_ACTION 参数的 mallopt

MALLOC_CHECK_ 环境变量

mcheck 系列函数

我发现可用的文档令人困惑。 manual在描述 mallopt 时根本没有列出 M_CHECK_ACTION。 This mallopt man page但是，确实描述了 M_CHECK_ACTION。此外，它说它相当于环境变量 MALLOC_CHECK_:

   MALLOC_CHECK_
          This environment variable controls the same parameter as
          mallopt() M_CHECK_ACTION.  If this variable is set to a
          nonzero value, then a special implementation of the memory-
          allocation functions is used.  (This is accomplished using the
          malloc_hook(3) feature.)  This implementation performs
          additional error checking, but is slower than the standard set
          of memory-allocation functions.

glibc 手册有一页 mcheck and friends并将它们描述为“堆一致性检查”。手册在此页面上讨论了 MALLOC_CHECK_:

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).

所以 mcheck et al 是 MALLOC_CHECK_/M_CHECK_ACTION 的替代品？

此外，如何禁用所有这些 super 有用的一致性检查？手册页说将 MALLOC_CHECK_(因此 M_CHECK_ACTION)设置为 0 将不会使用“内存分配函数的特殊实现”。然而，glibc 手册指出“当设置 MALLOC_CHECK_ 时，将使用特殊的(效率较低的)实现。”仍然设置了设置为 0 的环境变量，因此其中一个是错误的。

我自己的实验(使用 this mcheck man page 中的示例程序)表明完全没有设置 MALLOC_CHECK_ 会导致与 MALLOC_CHECK_=3 相同的行为(在 RHEL 6.4 上)。和 mcheck 似乎完全无关，因为它可以独立设置。

Answer 1

有四种不同的一致性检查。以下对应glibc 2.25。

各种断言。它们是否处于事件状态是在构建 glibc 时确定的。过去，Debian 和下游都打开了断言。 Fedora 和下游在过去禁用了它们(但当前的 Fedora 保留了它们)。

核心 malloc 实现中的一致性检查，不使用断言，但 malloc_printerr 。过去，可以使用 MALLOC_CHECK_=0 (和 mallopt )关闭它们。但是，我怀疑 malloc_printerr 之后的错误恢复在所有情况下都是正确的，所以这不太可能奏效。如果存在堆损坏，程序可能很快就会崩溃。

相对轻量级的堆缓冲区溢出检测。这是由 MALLOC_CHECK_=3 (或另一个非零值)启用的。这不能通过 mallopt 打开。它是通过增加分配的大小并存储一些填充并在某些地方检查它来实现的。这个堆检查器应该是线程安全的，它与 malloc 内部紧密耦合。但是，它很少使用，因此很容易出现烦人的错误。

mcheck 函数，通过与 __malloc_initialize_hook 链接从 libmcheck.a 调用。这与之前的检查完全不同。我认为这个想法是通过拥有一组单独的元数据(独立于实际分配器)来验证正确的分配行为，并且 mcheck 不依赖于 glibc malloc 内部，除了 malloc Hook 。然而，它对这些钩子(Hook)的使用完全不是线程安全的。我认为今天没有人使用 mcheck 。它只是被包括在内，因为还没有人删除它。 (向后兼容甚至不需要它，因为不能保证检测到所有堆损坏，并且损坏堆的应用程序仍然完全未定义，因此无法检测 mcheck 是否实际执行额外检查。)

除此之外，还有 MALLOC_PERTURB_ ，可用于检测对未初始化或已释放数据的某些形式的访问。