Re: Use of mcheck during GDB development

[Pedro Alves <palves at redhat dot com>]

On 11/15/2016 08:22 PM, 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?

Here's an example:

  https://sourceware.org/ml/gdb-patches/2016-03/msg00125.html

> 
>>> 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.

OK.  In that case, it doesn't make a difference for us whatever you
decide to do.  We have a --enable-libmcheck configure switch already.
Worse that'll happen is that we'll switch the default to off.
It's already off by default for most developers, because mcheck is
incompatible with Python+threads (see gdb/configure.ac).

>>> 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 definitely appreciate you reaching out.  I was
wondering about the point of a warning at compile/build time, not
about deprecation notice via NEWS/email etc.  Maybe a compile/link
warning in advance will make projects add configure switches to
disable mcheck if they don't have them (though I doubt there's
such a case).

Anyway, it's just a checker; if it goes away at some point
because no one wants to support it, then we'll just have to
stop enabling it.

> 
> I think most people use valgrind for memory debugging.

Yeah, or address sanitizer, which would be closer to being
something you could always have on.  Valgrind is too heavyweight
for everyday use.  I believe we're not asan clean yet, unfortunately,
but we're slowly getting there.

Thanks,
Pedro Alves