问题
I'm running bash v4.4.19(1)-release on Ubuntu 18.10. If I run valgrind on a simple script (or even bash --version), I'm seeing that I definitely lost 12 bytes of memory and there's on the order of 46kB still reachable. The still reachable memory doesn't bother me so much since I know bash is going to do it's thing with process handling and deallocation, but what I don't understand is why I'm losing these 12 bytes.
Here's an example of a simple test script I'm using (filename is t.bash):
#!/bin/bash
A=2
((++A))
echo $A
I've also tried with unset A at the end of the script, which results in around 14 bytes less in the 'still reachable' section of the valgrind output (which makes sense). I'm calling valgrind as valgrind ./t.bash (or even valgrind bash --version just to see if that seems to leak too, which it does).
Is this normal? In meatier scripts, I'm finding the same results, with each spawn of bash 'definitely losing' 12 bytes.
Sample valgrind output for the script above:
ctimm@gordon:~$ valgrind ./t.bash
==37810== Memcheck, a memory error detector
==37810== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==37810== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==37810== Command: ./t.bash
==37810==
3
==37810==
==37810== HEAP SUMMARY:
==37810== in use at exit: 45,729 bytes in 641 blocks
==37810== total heap usage: 766 allocs, 125 frees, 55,160 bytes allocated
==37810==
==37810== LEAK SUMMARY:
==37810== definitely lost: 12 bytes in 1 blocks
==37810== indirectly lost: 0 bytes in 0 blocks
==37810== possibly lost: 0 bytes in 0 blocks
==37810== still reachable: 45,717 bytes in 640 blocks
==37810== suppressed: 0 bytes in 0 blocks
==37810== Rerun with --leak-check=full to see details of leaked memory
==37810==
==37810== For counts of detected and suppressed errors, rerun with: -v
==37810== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
And for running valgrind over bash --version with full leak check showing all leak kinds:
ctimm@gordon:~$ valgrind --leak-check=full --show-leak-kinds=all bash --version
==39097== Memcheck, a memory error detector
==39097== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==39097== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==39097== Command: bash --version
==39097==
GNU bash, version 4.4.19(1)-release (x86_64-pc-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.
==39097==
==39097== HEAP SUMMARY:
==39097== in use at exit: 17 bytes in 2 blocks
==39097== total heap usage: 153 allocs, 151 frees, 21,051 bytes allocated
==39097==
==39097== 5 bytes in 1 blocks are still reachable in loss record 1 of 2
==39097== at 0x483774F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==39097== by 0x19007D: xmalloc (in /bin/bash)
==39097== by 0x1351FA: main (in /bin/bash)
==39097==
==39097== 12 bytes in 1 blocks are definitely lost in loss record 2 of 2
==39097== at 0x483774F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==39097== by 0x19007D: xmalloc (in /bin/bash)
==39097== by 0x189A7A: set_default_locale (in /bin/bash)
==39097== by 0x134EA6: main (in /bin/bash)
==39097==
==39097== LEAK SUMMARY:
==39097== definitely lost: 12 bytes in 1 blocks
==39097== indirectly lost: 0 bytes in 0 blocks
==39097== possibly lost: 0 bytes in 0 blocks
==39097== still reachable: 5 bytes in 1 blocks
==39097== suppressed: 0 bytes in 0 blocks
==39097==
==39097== For counts of detected and suppressed errors, rerun with: -v
==39097== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Thanks.
来源：https://stackoverflow.com/questions/53553905/is-bash-leaking-memory