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