Re: Use of mcheck during GDB development

Mike Frysinger
2016-11-15T20:46:09Z

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On 15 Nov 2016 21:22, Florian Weimer wrote:
> On 11/15/2016 09:03 PM, Pedro Alves wrote:
> > On 11/15/2016 04:00 PM, Florian Weimer wrote:
> >> We need to get rid of the mcheck functionality in glibc because we
> >> really, really want to stop calling the malloc hook functions.
> >>
> >> A future glibc version will provide a lightweight heap checker, with
> >> functionality comparable to mcheck (but thread-safe!) as linkable and
> >> LD_PRELOAD-able (perhaps under a different name than libmcheck).
> >>
> >> How critical is the mcheck functionality to GDB development?
> >
> > Despite its flaws, it catches bugs. It's lightweight enough that
> > it can be on all the time. It's nice to have, IMO.
>
> Interesting. Do you know which mcheck bits actually catch failures?
> ...
> I think most people use valgrind for memory debugging.

or ASAN. that seems like a much saner project to migrate to.
i suspect all the bugs mcheck would catch, ASAN would too, and
it'd catch even more since ASAN includes stack coverage.

ASAN is in gcc-4.8+.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]