[RFC] Deprecating mtrace?

Tom Tromey tromey@redhat.com
Mon Nov 4 17:13:00 GMT 2013


>>>>> "Ondřej" == Ondřej Bílka <neleai@seznam.cz> writes:

Ondřej> Also to part it work, to quote ulrich:

Ondřej> "mcheck does not work for multi-threaded code. It cannot possibly do.
Ondřej> There is no way to fix this with the technology underlying mcheck."

Ondřej> which speaks for itself as one can write a standalone portable leak
Ondřej> detector that is faster, supports multithreading and does not need
Ondřej> modification of binary in weekend.

The above statement is true of the way mcheck is currently implemented.
Nothing says that it has to be implemented this way, though, or that
"son of mcheck" couldn't be done better.

In gdb we enabled mcheck by default for development builds, when it was
found on the host system.  This caught real bugs during testing and was
cheap enough to simply enable all the time.

However we had to disable it once we allows multi-threading with Python.
This was a real loss.

Running the test suite under valgrind also has caught bugs, but it is
too slow to always be enabled.

So from our perspective, mcheck is a useful feature, which could be
improved.  We wish it were.

Tom



More information about the Libc-alpha mailing list