On 13 April 2017 at 16:46, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 11:41 AM, Reuben Thomas wrote: > > > This is not the result I obtained. I simply ran gdb on the bash binary, > > valgrind was not involved. > > If you didn't build the binary yourself,
I did, from git master. Sorry that wasn't clear. Thanks for your gdb traces. Here's mine on Ubuntu 16.04: $ ./bash --version GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ gdb ./bash GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./bash...done. (gdb) b xfree Breakpoint 1 at 0x47ca80: file xmalloc.c, line 147. (gdb) r -c '' Starting program: /home/rrt/.local/var/repo/bash/bash -c '' s is 0x721368 s is 0x721368 string is 0x721368 Breakpoint 1, xfree (string=0x721368) at xmalloc.c:147 147 if (string) (gdb) s 148 free (string); (gdb) s internal_free (mem=0x721368, file=0x0, line=0, flags=<optimised out>) at malloc.c:846 846 malloc.c: No such file or directory. (gdb) s 858 in malloc.c (gdb) p free $1 = {void (void *)} 0x7ffff7df0d80 <free> (gdb) So it seems I misunderstood what gdb was telling me: "p free" gives the address of glibc free (even if I do it inside xfree). But it is running bash's free. (There are some extra diagnostics there which are debugging statements I put in.) Meanwhile, in the valgrind bug report, Mark Wielaard observed: "I think the problem is that bash not only has its own malloc/free implementation (valgrind should intercept that just fine). But also has malloc wrappers for some malloc functions that call their internal counterparts directly (so valgrind won't know that is a matching allocation/deallocation function)." Mark manages to fix the problem by defining DISABLE_MALLOC_WRAPPERS, which is at least less drastic than configuring --without-bash-malloc. I shall pursue the matter on the Valgrind side. Mark also says that compiled thus he finds some small memory leaks in bash, so I'll report back if I can confirm. Thanks very much again for your help with this problem. -- http://rrt.sc3d.org
