I'm glad to see the issue is not widespread, for sure! I'm running fully updated Pop! OS 20.04 (debian based), which also has an older version of bash (installed natively).
Bash Version: 5.0Patch Level: 17Release Status: release Hopefully the issue has already been fixed, and the `apt` packages can be updated. If it's not that simple, then I'm happy to continue running tests on my machine. Unfortunately, I have exhausted my `bash` debugging knowledge at this point, and I will require guidance as to how I may collect more/better logs. Sincerely,Zak On Tuesday, June 15, 2021, 03:20:27 PM CDT, Chet Ramey <chet.ra...@case.edu> wrote: On 6/15/21 3:19 PM, Zachary Fields wrote: > Again, this can be reproduced with only Valgrind and Bash installed, by > copy/pasting the following command: Don't be so sure: ==34794== LEAK SUMMARY: ==34794== definitely lost: 0 bytes in 0 blocks ==34794== indirectly lost: 0 bytes in 0 blocks ==34794== possibly lost: 0 bytes in 0 blocks ==34794== still reachable: 20,847 bytes in 464 blocks ==34794== suppressed: 0 bytes in 0 blocks on RHEL 7 with the current devel version and ==34900== ==34900== All heap blocks were freed -- no leaks are possible ==34900== with bash-5.1.8. > ==53602== 2 bytes in 1 blocks are definitely lost in loss record 10 of 264 > ==53602== at 0x483C7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==53602== by 0x198523: xmalloc (in /usr/bin/bash) > ==53602== by 0x19199E: set_default_locale (in /usr/bin/bash) > ==53602== by 0x136C8A: main (in /usr/bin/bash) It depends on the libc implementation of setlocale(3). This has come up a number of times before: https://lists.gnu.org/archive/html/bug-bash/2015-07/msg00073.html https://lists.gnu.org/archive/html/bug-bash/2017-04/msg00063.html https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00052.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
