Re: Running bash under valgrind gives "invalid free()"

[Chet Ramey]

On 4/13/17 10:33 AM, Reuben Thomas wrote:
> On 12 April 2017 at 15:49, Chet Ramey <chet.ramey@case.edu
> <mailto:chet.ramey@case.edu>> wrote:
> 
> 
>     It's a false positive, or a bug in valgrind. I took a quick look.  There's
>     one place in this code path where free() gets called.
> 
> 
> ​Julian Seward (valgrind author) pointed out:​
> 
> "
> ​…​
> what you report is symptomatic of bash
> ​ ​
> using its own malloc to allocate a block but the system free to release
> ​ ​
> it.  Could that be the case?

I doubt it.

> ​"
> 
> I had a look. Certainly at xmalloc.c:148 where free is called by xfree from
> the cleanup function called at unwind_prot.c:333, gdb reports:
> 
> p free
> $7 = {void (void *)} 0x7ffff7df0d80 <free>
> 
> This is glibc free.
> 
> If I put a breakpoint on xmalloc and rerun, it is not hit.
> 
> If I put a breakpoint on shell.c:1399, and trace into savestring, I find it
> is running sh_xmalloc.

sh_xmalloc is just a wrapper that calls sh_malloc, in the same way that
xmalloc calls malloc.  sh_malloc is, in turn, a wrapper around bash's
internal malloc that adds file and line tracing information to the call.
The bash malloc() implementation simply calls this internal_malloc without
the file and line information.  You can freely mix calls to sh_malloc
and malloc without arena corruption.  It's easy to see what happens: the
bash calls get tracing, and malloc calls from libraries don't.  This is
exactly what you want.

Ths same thing happens with free: sh_xfree is a wrapper around sh_free
as xfree wraps free; sh_free is a wrapper that adds file and line
tracing to free.  The bash free() is a wrapper that calls internal_free
in the same fashion.

The normal bash allocation calls use these wrappers (defined in xmalloc.h)
so the tracing takes place and the trace information appears in error
messages, and can be optionally logged.

It doesn't make sense to do this in the unwind-protect calls because you're
calling through function pointers, so bash uses xfree. xfree calls free,
and doesn't require you to know whether free is a void or int function
(which used to matter more than it does now, but still matters on some
systems).  free is defined in the same file in the same (statically-
linked) library as the rest of the bash malloc functions.

I see no reason why, since all of these things are defined in the same
file and are statically linked, `free' would resolve to the glibc free
when malloc resolves to the bash malloc.

> So it seems that the malloc and free calls are mismatched.

Only in that they don't use the fixed names `malloc' and `free'.  If you
replace one set of names without the other, you'll produce false positives.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/