Huge memory leak, probably related to making new processes

Christopher Faylor
Wed Oct 3 04:31:00 GMT 2007

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:
>> 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).
>> Thanks for the note.
>I ran it for about 15 minutes, no problem.
>In general, you should be wary of what Task Manager is telling you. In this
>example, it doesn't make sense to me that memory could leak, because each of the
>(echo) processes is executing in a subshell, which terminates after completion.
>No matter what a process does in Windows, its memory is always returned when it
>terminates, unless it is doing something very unusual. (But, of course, cygwin's
>fork() does do something unusual...) You could try running some simple c++
>program, after it looks like your memory is exhausted, to allocate 1 GB of
>memory, and see if it succeeds. When it returns, the OS will probably report
>more free memory. This was the basis of some scam-ish "RAM cleaner" programs
>that really didn't do anything other than make Task Manager's output look nicer.
>That said, you are also describing some real symptoms of a problem, such as
>exhausting the physical memory and swapping. That should not occur, so there may
>be some problem that's beyond my experience. (In your example, I would have said
>that maybe the disk thrashing you experienced was caused by find itself, but if
>you also see it just from running this subshell loop, that is strange.) I guess
>it could be something going wrong with fork(), etc, that someone else on the
>list might know about. They'll probably ask you to check all the usual suspects
>first... are there any firewalls, AV scanners, etc, running in the background?
>If so, try getting rid of all of them and see if the problem still occurs. There
>are some poorly written ones that have been known to interfere with cygwin. Hope
>that helps...

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.  The other alternative is
misunderstanding of what is going on.  I'd say that it was probably
50/59 which is the case here.


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list