On 13 April 2017 at 22:05, Reuben Thomas <r...@sc3d.org> wrote: > > On 13 April 2017 at 21:17, Chet Ramey <chet.ra...@case.edu> 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). 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)." >> >> Yes, if he wants the details, feel free to forward my message from earlier >> today. >> > > Thanks, I > already linked to it in the valgrind bug report > . >
I've closed the Valgrind bug report WONTFIX. Mark Wielaard there kindly provides a patch to bash to make it play nicely with Valgrind, though I doubt you'll want to take it (just to be clear, I wouldn't if I were a bash maintainer!). Since RedHat and Fedora build --without-bash-malloc, that seems an acceptable solution for Debian/Ubuntu. (Not least, performance there is less of an issue since the default /bin/sh is no longer bash.) As Mark says, and if it hasn't already been tried, it would be good if any benchmarks could be brought to the attention of the glibc maintainers if there's potential for improvement in glibc's malloc. -- http://rrt.sc3d.org
