On 4/13/17 11:18 AM, Reuben Thomas wrote:
> On 13 April 2017 at 16:11, Chet Ramey <chet.ra...@case.edu
> <mailto:chet.ra...@case.edu>> wrote:
>
>
> 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 this is the real problem?
If it is, it's a valgrind artifact. Contrary to Julian's (?) assumption,
free() resolves to the bash free implementation when compiled normally. I
tested this on a Fedora 25 VM I was using for something else. Putting a
breakpoint in xfree, running bash -c '', and stepping through it ends up
in the free() defined in lib/malloc/malloc.c.
>
> Do you have any suggestions for how I might investigate this?
Personally, I think the problem is that valgrind makes invalid assumptions:
that interposing malloc/realloc/free is sufficient. I showed it isn't.
You can try building without the bash malloc, but that's kind of a drastic
solution to just get rid of a valgrind false positive.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
