Comment 11 for bug 82123

even if dash seems to be able to do this more efficiently and memory does not get reassigned until bash exits, I will close this now for the following reasons. As always, feel free to reopen if you have something to add or disagree and want some further discussion.

I talked extensively with some of the users and devs in #bash this morning. They were able to confirm the general findings in this ticket. They did some calculations which indicated to them that memory usage wasn't excessive or out of norm. I then ran valgrind to detect memory leaks (http://www.cprogramming.com/debugging/valgrind.html). The following caveats apply, I reduced the second loop by a factor of 100, since otherwise the machine would run out of memory. Furthermore, I ran this on a Debian, not a Ubuntu machine, since that was the only computer I had access to with 4G of physical RAM. The check indicated no memory leak.

$ valgrind --tool=memcheck --leak-check=yes /tmp/82123.sh | tee /tmp/valgrind.log
==17152== Memcheck, a memory error detector.
==17152== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==17152== Using LibVEX rev 1658, a library for dynamic binary translation.
==17152== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==17152== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==17152== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==17152== For more details, rerun with: -v
==17152==
Loop 1
Loop 2
Loop 3
Loop 4
Loop 5
Loop 6
Loop 7
Loop 8
Loop 9
Loop 10
==17152==
==17152== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==17152== malloc/free: in use at exit: 0 bytes in 0 blocks.
==17152== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==17152== For counts of detected errors, rerun with: -v
==17152== All heap blocks were freed -- no leaks are possible.

Thank you for reporting this issue.