MALLOC_CHECK Multithreaded or not?

Question

I am working on a multithreaded C application. Recently we observed some memory corruptions(very rare) . To identify that we were tested with -lmcheck linking . But after we came to know that -lmcheck is not thread safe. Then we start testing with MALLOC_CHECK=3 . Here I have a unsolved doubt I.e. -lmcheck and MALLOC_CHECK=3 behaviour same or not ? MALLOC_CHECK=3 thread safe or not ? If any one answers this it very helpful for me .. I tried with valgrind , electric fence but no use.

Answer 1

As per the GNU article on Heap consistency Checking mcheck is defined as MT-Unsafe.

Function: int mcheck (void (*abortfn) (enum mcheck_status status))

Preliminary: | MT-Unsafe race:mcheck const:malloc_hooks | AS-Unsafe corrupt | AC-Unsafe corrupt

MT-Unsafe, AS-Unsafe, AC-Unsafe functions are not safe to call within the safety contexts described above. Calling them within such contexts invokes undefined behavior.

So, what’s the difference between using MALLOC_CHECK_ and linking with ‘-lmcheck’?

MALLOC_CHECK_ is independent with respect to ‘-lmcheck’. ‘-lmcheck’ has been added for backward compatibility. Both MALLOC_CHECK_ and ‘-lmcheck’ should uncover the same bugs - but using MALLOC_CHECK_ you don’t need to recompile your application.

Setting MALLOC_CHECK_ :

If MALLOC_CHECK_ is set to 0 (zero), the memory management functions are simply most tolerant of errors and do not give warnings. Maybe be useful if we are prevented from finding one memory bug by another that is not convenient to fix at the moment; it might allow us to use other tools to chase down the other memory bug. It may also be useful if you are running code that works on another system but not on Linux. It can provide a quick workaround that may allow the code to temporarily function, before you have the chance to resolve the error.

If MALLOC_CHECK_ is set to 1 (one), the memory management functions print out warning messages on standard error when problems are noticed. It is useful if we are not aware of any problems and just want to be notified if any problem exist.

If MALLOC_CHECK_ is set to 2 (two), the memory management functions call abort()when problems are noticed. This is most useful from inside the debugger or a shell starting an application or daemon. It allows a backtrace to be obtained as soon as the memory management functions discover an error, providing information closest to the point at which the error has happened. If a core is caused by a memory corruption, we have more information about memory allocations. This is better for troubleshooting and determining where/which application overwrote a memory address.

Settings 1 and 2 can be combined by setting MALLOC_CHECK_ to 3 (three). This will enable the print out of warning messages on standard error (1), and will call abort() when problems are noticed (2).

For more information please go through this link for better understanding: Heap Consistency Checking

Answer 2

Since you can use the MALLOC_CHECK_ (note trailing underscore) approach without linking an external library, it seems reasonable to conclude that it engages a different implementation than libmcheck does. In any case, the two are both GNU extensions, documented as alternatives.

I suppose what you really want to know is whether using MALLOC_CHECK_ breaks thread safety of dynamic memory allocation. Glibc specifies that its malloc() implementation is thread safe (see for example, https://stackoverflow.com/a/27047048/2402272), as indeed POSIX requires. It is conceivable that its thread safety is broken by non-zero values of MALLOC_CHECK_, but that seems unlikely, and I find no documentation of such.