Mike Frysinger wrote:
> On Thursday 30 April 2009 05:56:02 Jan Schampera wrote:
>> Sandino Araico Sánchez wrote:
>>> 1.
>>> #!/bin/bash
>>> 2.
>>>
>>> 3.
>>> for i in {0..150000000} ; do
>>> 4.
>>> echo $i > /dev/null
>>> 5.
>>> done
>>>
>>>
>>>
>>> Repeat-By:
>>> Run the script above and the process starts leaking memory very
>>> fast.
>> You know what a memory *leak* is, yes? mallocs() without proper free()s.
>>
>> What you mean is that your memory is used. Feel free to calculate the
>> memory that is needed to store the string representation of
>> {0..150000000}, I think you will get a number near your RAM size.
>
> granted his example is wrong and his reasoning incorrect, there may actually
> be a leak here ...
>
> bash-4.0$ ps -p $$ -F
> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
> vapier 27999 16493 0 5675 3052 1 18:51 pts/1 00:00:00 bash --norc
> bash-4.0$ for n in {0..150000000} ; do echo $n; done
> <wait a few seconds>^C
> bash-4.0$ ps -p $$ -F
> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
> vapier 27999 16493 17 392694 473236 1 18:51 pts/1 00:00:01 bash --norc
>
> that memory never goes away and bash will chew significant CPU (~10%) while
> it
> should be idle ...
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
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
