O n 13 April 2017 at 16:27, Chet Ramey <chet.ra...@case.edu> wrote:
> 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. > This is not the result I obtained. I simply ran gdb on the bash binary, valgrind was not involved. Indeed, building --without-bash-malloc fixed it.
