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

[Reuben Thomas]

​O​

n 13 April 2017 at 15:33, Reuben Thomas <rrt@sc3d.org> wrote:

On 12 April 2017 at 15:49, Chet Ramey <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 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.

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

​Trying to understand this at a source level, if I capture the compilation command for evalstring.c​ and replace -c with -E to preprocess it, I see that the relevant line has become:

add_unwind_protect (xfree, orig_string)

where xfree is now the function name (in xmalloc.c).

So this still looks wrong (it should be sh_xfree, surely?).

--

http://rrt.sc3d.org