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?

On Mon, Nov 04, 2013 at 10:13:04AM -0700, Tom Tromey wrote:
> >>>>> "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.

I am writing checker that is more capable, now it detects double free,
writing before/past array, a version to emulate mtrace is here.

it is mostly lacking error reporting, for illegal writes it aborts, for
reporting leaks I could extract call address but turning them to
file/line pair is ugly.

One alternative would be could allocations and for leaks print
watchpoints that will stop at these allocations. 

For leaks it would be handy to know layout of static data to filter
allocations that are still reachable. As gdb can extract these from
debug information problem is how to make accessible to leak detector.
Also a gdb could benefit from this allocator as it could for given
address in heap tell lower and upper bound of allocated area.

> 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

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