X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
References: <13006193 DOT post AT talk DOT nabble DOT com> <fdudpa$anu$1 AT sea DOT gmane DOT org> <13010714 DOT post AT talk DOT nabble DOT com> <loom DOT 20071003T040816-588 AT post DOT gmane DOT org> <20071003043101 DOT GA2486 AT ednor DOT casa DOT cgf DOT cx>
Subject: RE: Huge memory leak, probably related to making new processes
Date: Wed, 3 Oct 2007 11:44:27 +0100
Message-ID: <007a01c805aa$5f235770$2e08a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20071003043101.GA2486@ednor.casa.cgf.cx>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 03 October 2007 05:31, Christopher Faylor wrote:

> On Wed, Oct 03, 2007 at 04:20:18AM +0000, Lewis Hyatt wrote:
>>> Anyway, can I ask you to do this yourself - just do the last test:
>>> 
>>> COUNTER=1
>>> while [ $COUNTER -lt 123456 ]; do (echo $COUNTER); let
>>> COUNTER=$COUNTER+1; done 
>>> 
>>> and wait a little (couple of minutes). If necessary, repeat it until your
>>> memory drops to 10-20 MB range and your HDD should start whining. Then
>>> close cygwin and wait 10 minutes. The memory is still "occupied". I don't
>>> know when Windows would free it, but I did not get that behavior with any
>>> other program (e.g. try to open & close Firefox or such - it will show a
>>> peak in both directions regarding memory and will do that almost
>>> immediately). 

  That's exactly what I see when I try your testcase.  No continuous increase
in any of the figures, I just see the commit charge go up a bit each time an
echo is launched and down a bit each time it terminates, about two meg
variation.  The same slight up-and-down variation in the physical memory
available/cache figures.  No change at all in the kernel memory figures.
 
> I've been waiting for someone to make the observation that Cygwin has no
> magic powers which allow it to allocate memory and never release it -
> even on process exit.  No modern OS allows you to get away with that.
> 
> If the OP is really seeing that then either there is something else on his
> system which is responsible for the behavior.  

  I suspect BLODA interference.  I'd particularly like the OP to report if
there is any leak in the kernel memory figures, because that would certainly
point the finger at a dodgy antivirus disk filter device driver or similar.

> The other alternative is
> misunderstanding of what is going on.  I'd say that it was probably
> 50/59 which is the case here.

  That's inflation for ya - 100% aint what it used to be.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/