Arthur Korn writes: > Hi > > Linux turing.prv.korn.ch 2.6.8-1-686 #1 Sat Aug 28 14:11:39 EDT 2004 i686 > GNU/Linux > ii bash 3.0-5 The GNU Bourne Again SHell > ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries and Timezone > > Regardless of this being a problem with the bash malloc or a > real memleak, this is a real problem, try this: > > Run $(seq $big_number) with $big_number adjusted to fill most of > your memory and swap. > > Start another bash, run another $(seq $big_number), while it is > running, you can tickle around in the first bash to make it wake > up. The first bash won't free any of the previously allocated > and now presumably unused memory before all memory is used up by > the second one and the OOM killer terminates something (usually > the first bash in my experiments). > > So bash doesn't release memory even if the system is under > memory pressure, which is _BAD_.
do you propose that applications should have a memory allocation strategy depending on the system state? It looks like you could file this kind of bug to any program, which doesn't free memory immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
