Using Criterion with mcheck results in strange crashes

[truh]

To do it's job mcheck has
to be initialised before memory gets allocated, otherwise the initialisation function mcheck(_)
returns a non-zero value, indicating an error. This effect can be seen with this short snippet of code:

#include <criterion/criterion.h>
#include <mcheck.h>
Test(mcheck, mcheck) {
    cr_assert_null(mcheck(NULL), "mcheck has to return zero.");
} 

As suggested via Gitter chat, I tried to put the initialisation routine in the constructor attribute of a separate shared library. This worked sometimes but most of the time resulted in one out of a variety
of different errors, including but not limited to:

• a large backtrace
• "memory clobbered before allocated block"
• "criterion: Could not spawn test instance: Protocol error"
• exit code 11, no error message

Example

Compile

gcc -shared -o libmcheck_workaround.so mcheck_workaround.c
gcc -lmcheck_workaround -lcriterion -I$HOME/include -L$PWD -L$HOME/lib test.c

mcheck_workaround.c

#include <stddef.h>
#include <mcheck.h>

__attribute__((constructor))
void init_mcheck(void) {
    mcheck(NULL);
}

test.c

#include <criterion/criterion.h>
#include <mcheck.h>

Test(test, trueistrue) {
    cr_assert(true, "true is true.");
}

[Snaipe]

After a more in-depth check, it turns out this is not fixable. mcheck and mprobe aren't thread safe, but are still called with multi-threaded malloc calls. This fails horribly with nanomsg, which uses threads internally and allocates memory on them.

I might re-investigate this if it were to happen again in the future and we were to not use nanomsg anymore. In the mean time, no one can fix this without gutting nanomsg, so I'll have to close this.