On 11/30/11 5:30 PM, Marc Schiffbauer wrote:
>> It's not a memory leak. It might reveal a sub-optimal memory allocation
>> pattern -- asking for an array with that many strings is going to gobble
>> a lot of memory -- but it's not a leak in the sense that bash loses
>> track of an allocated chunk.
>
> Well, but how do you explain that:
>
> mschiff@moe:~$ bash
> mschiff@moe:~$ ps u $$
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> mschiff 14156 5.2 0.1 8836 3692 pts/1 S 23:28 0:00 bash
> mschiff@moe:~$ time echo {0..1000000}>/dev/null
>
> real 0m2.307s
> user 0m2.084s
> sys 0m0.196s
> mschiff@moe:~$ ps u $$
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> mschiff 14156 13.2 6.2 196272 191036 pts/1 S 23:28 0:02 bash
> mschiff@moe:~$
That's probably the result of the power-of-two allocation policy in the
bash malloc. When this came up before, I wrote:
==========
That's not a memory leak. Malloc implementations need not release
memory back to the kernel; the bash malloc (and others) do so only
under limited circumstances. Memory obtained from the kernel using
mmap or sbrk and kept in a cache by a malloc implementation doesn't
constitute a leak. A leak is memory for which there is no longer a
handle, by the application or by malloc itself.
==========
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
