O
n 13 April 2017 at 15:33, Reuben Thomas <r...@sc3d.org> wrote:
> On 12 April 2017 at 15:49, Chet Ramey <chet.ra...@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
