glibc的MALLOC_CHECK_，M_CHECK_ACTION和mcheck有什么区别？ [英] What is the difference between glibc's MALLOC_CHECK_, M_CHECK_ACTION, and mcheck?

问题描述

glibc似乎有多种方法来进行堆检查：

glibc seems to have more than one way of doing some heap checking:

1. 带有M_CHECK_ACTION参数的mallopt


2. MALLOC_CHECK_环境变量


3. mcheck函数家族

现有文档令人困惑。 手册根本没有列出M_CHECK_ACTION描述Mallopt时。 此mallopt手册页，但确实描述M_CHECK_ACTION。另外，它说它等效于环境变量MALLOC_CHECK _：

I find the available documentation to be confusing. The manual doesn't list M_CHECK_ACTION at all when describing mallopt. This mallopt man page, however, does describe M_CHECK_ACTION. Additionally, it says it's equivalent to the environment variable 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和朋友，并将它们描述为堆一致性检查。手册在此页面上讨论MALLOC_CHECK _：

The glibc manual has a page for mcheck and friends and describes them as "heap consistency checking". It is on this page that the manual discusses MALLOC_CHECK_:

另一种可能性可以检查和防范使用malloc，realloc和free是设置环境变量MALLOC_CHECK_。设置MALLOC_CHECK_时，将使用一种特殊的（效率较低的）实现，该实现旨在容忍简单的错误，例如使用相同参数对free的两次调用或单个字节的超限（一次性错误）。

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等人可以替代MALLOC_CHECK_ / M_CHECK_ACTION？

So mcheck et al is an alternative to MALLOC_CHECK_/M_CHECK_ACTION?

此外，如何禁用所有这些超级有用的一致性检查？手册页说将MALLOC_CHECK_（因此也将M_CHECK_ACTION）设置为0将不会使用内存分配功能的特殊实现。但是，glibc手册指出：设置MALLOC_CHECK_时，将使用特殊的（效率较低）实现。仍然设置为0的环境变量，所以其中之一是错误的。

Furthermore, how does one disable all this super-helpful consistency checking? The man page says setting MALLOC_CHECK_ (and therefore M_CHECK_ACTION) to 0 will not use "a special implementation of the memory-allocation functions." The glibc manual, however, states that "When MALLOC_CHECK_ is set, a special (less efficient) implementation is used." An environment variable set to 0 is still set, so one of these is wrong.

我自己的实验（使用来自此mcheck手册页）显示未完全设置MALLOC_CHECK_的行为与MALLOC_CHECK_ = 3相同（在RHEL 6.4上）。而且mcheck似乎完全无关，因为它可以独立设置。

My own experiments (using the example program from this mcheck man page) show that not having MALLOC_CHECK_ set at all results in the same behavior as MALLOC_CHECK_=3 (on RHEL 6.4). And mcheck seems completely unrelated, as it can be set independently.

推荐答案

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

There are four different consistency checks. The following corresponds to glibc 2.25.

1. 各种断言。它们是否处于活动状态是在构建glibc时确定的。过去，Debian及其下游保留断言处于打开状态。 Fedora和下游公司过去曾禁用它们（但当前的Fedora保留了它们）。


2. 核心 malloc 实现中的一致性检查不使用断言，而是使用 malloc_printerr 。过去，可以使用 MALLOC_CHECK_ = 0 （和 mallopt ）将其关闭。但是，我怀疑 malloc_printerr 之后的错误恢复在所有情况下都是正确的，因此这不太可能起作用。而且，如果有堆损坏，程序也可能很快崩溃。


3. 相对轻量的堆缓冲区溢出检测。这可以通过 MALLOC_CHECK_ = 3 （或另一个非零值）启用。 mallopt 无法启用此功能。通过增加分配大小并存储一些填充并在某些地方检查它来实现。该堆检查器应该是线程安全的，并且与 malloc 内部紧密关联。但是，它很少使用，因此很容易出现烦人的bug。


4. 函数，从 libmcheck.a > __ malloc_initialize_hook 。这与以前的检查完全不同。我认为这个想法是通过使用单独的元数据集（独立于实际分配器）来验证正确的分配行为，并且 mcheck 不依赖于 glibc malloc内部，但 malloc 钩子除外。但是，使用这些钩子完全不安全。我认为今天没有人使用 mcheck 。它被包括在内是因为还没有人删除它。 （甚至不需要向后兼容，因为不能保证检测到所有堆损坏，并且破坏堆的应用程序仍然是完全未定义的，因此无法检测 mcheck 实际上会执行其他检查。）

1. Various asserts. Whether they are active is determined when glibc is built. In the past, Debian and downstreams left asserts switched on. Fedora and downstreams disabled them in the past (but current Fedora leaves them on).
2. Consistency checks in the core malloc implementation which do not use asserts, but malloc_printerr. In the past, they could be switched off using MALLOC_CHECK_=0 (and mallopt). However, the I doubt that the error recovery after malloc_printerr is correct in all cases, so this is unlikely to work. And if there is heap corruption, the program might crash soon anyway.
3. Relatively lightweight heap buffer overflow detection. This is enabled by MALLOC_CHECK_=3 (or another non-zero value). This cannot be switched on by mallopt. It is implemented by increasing the size of allocations and storing some padding and checking it in some places. This heap checker should be thread-safe, and it is tightly coupled with malloc internals. However, it is rarely used, so there could easily be annoying bugs.
4. The mcheck function, called from __malloc_initialize_hook by linking with libmcheck.a. This is completely different from the previous checks. I think the idea is to verify correct allocation behavior by having a separate set of metadata (independent of the actual allocator), and mcheck does not depend on the glibc malloc internals except for the malloc hooks. However, its use of these hooks completely not thread safe. I don't think anyone uses mcheck today. It is just included because no one has removed it yet. (It is not even needed for backwards compatibility because there is no guarantee that all heap corruption is detected, and applications which corrupt the heap are still completely undefined, so there is no way to detect whether mcheck actually performs additional checks.)

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

In addition to that, there is also MALLOC_PERTURB_, which can be used to detect some forms of access to uninitialized or freed data.

这篇关于glibc的MALLOC_CHECK_，M_CHECK_ACTION和mcheck有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！