Re: Memory leak in for loops

[Mike Frysinger]

On Monday 04 May 2009 21:12:15 Chet Ramey wrote:
> 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.

yes, i know what a leak is, but i hadnt thought of the glibc allocator caching 
the memory itself.  i imagine the cpu usage is simply the glibc allocator 
walking its internal structures.

i also dont really care enough about the issue to prove whether it's actually 
the glibc malloc implementation at fault vs bash not doing the right thing.
-mike

signature.asc
Description: This is a digitally signed message part.