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

On 13 April 2017 at 21:17, Chet Ramey wrote: > On 4/13/17 3:57 PM, Reuben Thomas wrote: > > > 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). Bu

Re: Leaks detected by valgrind

On 4/13/17 4:12 PM, Reuben Thomas wrote: > Here they are. I guess you probably won't care about them as as far as I > can see they are all one-off allocations at initialization: > > ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249 > ==1289==at 0x4C2DB2F: malloc (in

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

On 4/13/17 3:57 PM, Reuben Thomas wrote: > 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 th

Leaks detected by valgrind

Here they are. I guess you probably won't care about them as as far as I can see they are all one-off allocations at initialization: ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249 ==1289==at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so

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

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

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

On 4/13/17 11:46 AM, Chet Ramey 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, you don't know what changes were > made to it. Here's what

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

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, you don't know what changes were made to it. Here's what I got on Fedora 25. [chet@caleb-fedora25 bash-2017

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

​O​ n 13 April 2017 at 16:27, Chet Ramey wrote: > On 4/13/17 11:18 AM, Reuben Thomas wrote: > > On 13 April 2017 at 16:11, Chet Ramey > > wrote: > > > > > > I see no reason why, since all of these things are defined in the > same > > file and are statically li

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

On 4/13/17 11:18 AM, Reuben Thomas wrote: > On 13 April 2017 at 16:11, Chet Ramey > 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 r

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

On 13 April 2017 at 16:11, Chet Ramey 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?​ ​Do you have any suggestions

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

On 4/13/17 10:55 AM, Reuben Thomas wrote: > ​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 no

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

On 4/13/17 10:33 AM, Reuben Thomas wrote: > On 12 April 2017 at 15:49, Chet Ramey > 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

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

​O​ n 13 April 2017 at 15:33, Reuben Thomas wrote: > On 12 April 2017 at 15:49, Chet Ramey 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:​ > > "

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

On 12 April 2017 at 15:49, Chet Ramey 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 mall

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

On 4/13/17 6:32 AM, Reuben Thomas wrote: > Obviously a bug in valgrind, but I am interested: why does bash not use the > glibc malloc by default on GNU/Linux systems? The bash malloc is faster; better tuned for bash; is more signal safe without the twisty maze of locks that the glibc malloc uses;

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

On 13 April 2017 at 09:15, Reuben Thomas wrote: > > Having confirmed Chet's analysis with a few printfs added to bash (i.e. > just to check the address being allocated and the one complained about were > the same) I've filed a bug report against valgrind: > https://bugs.kde.org/show_bug.cgi?id=37

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

On 12 April 2017 at 17:58, Hanno Böck wrote: > On Wed, 12 Apr 2017 14:59:26 +0100 > Reuben Thomas wrote: > > > ​frequently, it's the only tool that shows up bugs of this sort, as > > it's rather more powerful than a debugging malloc library.) > > Try address sanitizer, it's pretty reliable and f