bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Severe memleak in sequence expressions?


From: Chet Ramey
Subject: Re: Severe memleak in sequence expressions?
Date: Wed, 30 Nov 2011 20:54:10 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]