Use of mcheck during GDB development

Use of mcheck during GDB development

[Florian Weimer]

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?  Would it 
be a problem if next glibc release would issue a deprecation warning 
without actually having a suitable replacement in-tree?

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.

Thanks,
Florian

Re: Use of mcheck during GDB development

[Pedro Alves]

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.

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

Thanks,
Pedro Alves

Re: Use of mcheck during GDB development

[Florian Weimer]

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

Re: Use of mcheck during GDB development

[Mike Frysinger]

[-- 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 --]

Re: Use of mcheck during GDB development

[Pedro Alves]

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

Re: Use of mcheck during GDB development

[Simon Marchi]

On 2016-11-15 15:50, Pedro Alves wrote:
> 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.

I occasionally build GDB with ASAN when chasing specific bugs, and it's 
been clean for my practical purposes.  Except for many warnings in 
libpython at startup, I don't know whether they're real or false 
positives.

Re: Use of mcheck during GDB development

[Pedro Alves]

On 11/15/2016 09:58 PM, Simon Marchi wrote:
> On 2016-11-15 15:50, Pedro Alves wrote:
>> 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.
> 
> I occasionally build GDB with ASAN when chasing specific bugs, and it's
> been clean for my practical purposes.  Except for many warnings in
> libpython at startup, I don't know whether they're real or false positives.

I meant when running the GDB testsuite against it.  Do you know whether asan
vs non-asan is regression free for you?  I haven't tried in a while.

Thanks,
Pedro Alves

Re: Use of mcheck during GDB development

[Simon Marchi]

On 2016-11-15 17:07, Pedro Alves wrote:
> On 11/15/2016 09:58 PM, Simon Marchi wrote:
>> On 2016-11-15 15:50, Pedro Alves wrote:
>>> 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.
>> 
>> I occasionally build GDB with ASAN when chasing specific bugs, and 
>> it's
>> been clean for my practical purposes.  Except for many warnings in
>> libpython at startup, I don't know whether they're real or false 
>> positives.
> 
> I meant when running the GDB testsuite against it.  Do you know whether 
> asan
> vs non-asan is regression free for you?  I haven't tried in a while.

Ah no I've never tested that.  But if we have enough resources for the 
buildbot, we should run an x86 job with it enabled.

Re: Use of mcheck during GDB development

[Yao Qi]

On Tue, Nov 15, 2016 at 8:22 PM, Florian Weimer <fweimer@redhat.com> wrote:
>
> I think most people use valgrind for memory debugging.
>

FWIW, I use asan and valgrind for memory debugging in gdb work.

-- 
Yao (齐尧)