Re: Use of mcheck during GDB development

[Florian Weimer <fweimer@redhat.com>]

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?

>> Would it
>> be a problem if next glibc release would issue a deprecation warning
>> without actually having a suitable replacement in-tree?
>
> Will that cause build problems with -Werror?

I don't know.  As far as I can tell, you just link with -lmcheck.  This 
should give you at most a link-time warning, which wouldn't fail the build.

>> I want to get the deprecation notice out as soon as possible, but I
>> might not be able to finish the mcheck replacement in time for the next
>> glibc release.
>
> If there's no replacement that users can move to, what's the point
> of warning soon?  Is there an advantage vs only when the replacement
> exists?

We can incorporate feedback from existing users into the design of the 
replacement.  We wouldn't be having this conversation if I didn't 
announce my intent to deprecate without immediate replacement from the 
glibc side.

I think most people use valgrind for memory debugging.

Thanks,
Florian