bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running bash under valgrind gives "invalid free()"


From: Reuben Thomas
Subject: Re: Running bash under valgrind gives "invalid free()"
Date: Thu, 13 Apr 2017 20:57:06 +0100

On 13 April 2017 at 16:46, Chet Ramey <address@hidden> 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.

--

reply via email to

[Prev in Thread] Current Thread [Next in Thread]