This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Deprecating mtrace?

>>>>> "OndÅej" == OndÅej BÃlka <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]