How important is mcheck?

How important is mcheck?

[Florian Weimer]

GDB enables mcheck if available, unless Python with threading support is 
built in (which most distributions do).  I've proposed to deprecate 
mcheck in glibc, with a goal towards eventually replacing it with stubs 
unavailable to newly compiled programs.  GDB would still run (and 
compile), albeit without mcheck support.

I see two bug reports about issues discovered with mcheck, so maybe it 
is useful.

Could you move mcheck in-tree?  Then you'd be able to enable it 
regardless of Python threading support.

-- 
Florian Weimer / Red Hat Product Security Team

Re: How important is mcheck?

[Tom Tromey]

>>>>> "Florian" == Florian Weimer <fweimer@redhat.com> writes:

Florian> I see two bug reports about issues discovered with mcheck, so maybe it
Florian> is useful.

Florian> Could you move mcheck in-tree?

mcheck's been discussed a few times on the gdb lists (I forget which) in
the past; and also at least once on the glibc list.

Some nice things about mcheck are that it is low cost and easy to enable
by default for development builds; since many developers are on
glibc-based systems, it can help catch simpler bugs.  As you found it
caught a few in the past.

I suppose we could have main call mcheck.  That seems only mildly more
difficult.

Florian> Then you'd be able to enable it regardless of Python threading
Florian> support.

The problem is that mcheck is written in a way that inherently not
thread-safe.  This requires a fix in glibc.

Tom

Re: How important is mcheck?

[Jan Kratochvil]

On Mon, 10 Feb 2014 16:50:20 +0100, Florian Weimer wrote:
> Could you move mcheck in-tree?

IMO mcheck has been obsoleted by asan (=gcc -fsanitize=address).

I just do not run GDB regularly under asan yet as in that case one can no
longer use 'ulimit -v 1000000' to catch GDB memory runaways.
	ERROR: AddressSanitizer failed to allocate 0x400000000 (17179869184) bytes at address 0x00067fff8000 (12)
	ReserveShadowMemoryRange failed while trying to map 0x400000000 bytes. Perhaps you're using ulimit -v

Unfortunately 'ulimit -m' (=RSS) has no effect so one has to give up on the
memory limit for GDB.  But it should be worth the asan improved checks.


Jan

Re: How important is mcheck?

[Florian Weimer]

On 02/11/2014 06:04 PM, Tom Tromey wrote:

> I suppose we could have main call mcheck.  That seems only mildly more
> difficult.

I would make it completely unavailable.

> Florian> Then you'd be able to enable it regardless of Python threading
> Florian> support.
>
> The problem is that mcheck is written in a way that inherently not
> thread-safe.  This requires a fix in glibc.

I somewhat naively assumed that GDB uses the xmalloc function variants 
consistently, but that doesn't seem to be the case.  If it did, just 
hooking the x* functions would do the trick.

-- 
Florian Weimer / Red Hat Product Security Team

Re: How important is mcheck?

[Tom Tromey]

Florian> I would make it completely unavailable.

Ok, I see.

If gdb is the only remaining user, then IMO don't let it stand in the
way of progress, particularly given what Jan said.

Tom