X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=DK7orNODuGcWouvcE0nvAIoso/8WKzISpQxrtuTZfo6
	qT/PrVX26D0hwTedYD9P2FS772Ifu14Vr4laprrzn/rc7biofhztfwWe5fy0FqaJ
	myAx61mKa+8f0NSvCuUU7e4xoIIMeuanCWPE7hA8j5vQDeXuMPqw5tSeJw2xqfNE
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=mi4KMAm/VtdrKVxkdUD962lprXA=; b=O7AAxu+1Zwgdw2weu
	IY10VkK7m08QoFIg+SJ06hVH04gLzhQAxNEf+7aw2gzHSNhnhgyahZ5OmLUO3E7c
	YryifxyQOH0g6wi3JnJ6nuIQHgIoXvgYG3uU3NY03T7M/ErLGjbWKwXy0g3LQV1I
	rSBKqapcqajX9uAkzo1FKE/Dms=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_RP_RNBL,SPF_PASS autolearn=no version=3.3.2
X-HELO:	www.titera.eu
Message-ID:	<54872069.4010501@titera.eu>
Date:	Tue, 09 Dec 2014 17:16:41 +0100
From:	=?UTF-8?B?UGV0ciBUaXTEm3Jh?= <petr AT titera DOT eu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version:	1.0
To:	Doug Lewan <dougl AT shubertticketing DOT com>,
	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	Re: Possible resource leak
References:	<5486B88D DOT 1040303 AT titera DOT eu> <155DEC68569B714B86C2C7075F5EDA9892B9D411 AT DAKIYA1 DOT pegasus DOT local>
In-Reply-To:	<155DEC68569B714B86C2C7075F5EDA9892B9D411@DAKIYA1.pegasus.local>

On 9.12.2014 16:30, Doug Lewan wrote:
> Petr,
>
> You write:
>> -----Original Message-----
>> Subject: Possible resource leak
>>
>> I'm dealing with possible resource leak in cygwin on Windows-7. I'm
>> running a script which repeatedly calls another script (every 5
>> seconds). After a while script ends with memory error. All my memory
>> seems to be eaten by Page Table entries and in the memory map I see a
>> lot of cygwin processes with 4 pages allocated (I can provide
>> screenshot
>> if neccessary). Is this known issue?
> A few questions come to mind.
>
> Can you tell which processes are staying around?
> Use CYGWIN's ps(1); Window's Task Manager is likely to show only bash.exe.

Nearly all. I see a lot (read thousands after some time) of bash.exe, 
wget.exe, date.exe and sleep.exe processes. The problem is that not ps 
or Task Manager shows anything. I had to use RamMap from sysinternals to 
display them, all of them seems to me just like process zombies (i.e. 
they have only one private page allocated and four pages in page table).

> Are you sure that all of wget(1)'s resources have been freed
> before it gets invoked again?
I'm not sure about that but i thought that all process resources should 
be freed before process exits or shortly after that, on my other machine 
I see some (read three or five) of these 'zombie' processes when I run 
my testing scripts.
> It surely uses things (IP stack, IP connections for example) that the Windows kernel manages.
> Similarly, sleep(1)'s main resource is interrupts, probably also eventually coming from the kernel.
> Perhaps there's a lock you should check (or create).
>
> You'll also be sleeping 0 seconds about every 5th cycle;
> maybe you should sleep $(( RANDOM%5 + 1 )) to make sure some sleeping always happens.

This doesn't bother me so much. These sleeps are there only to not 
overload server on other side too much. Occasional back-to-back request 
should be OK.

> Every call to fetchData.sh is another fork()/exec()
> which has to re-establish the definitions of getFileNoCheck() and getFileCheck().
> It might be better to put everything into main.sh.
To be hones at this time I do not care much about performance of this 
scripts (sleeps will make them really slow).

> Just some quick thoughts. It's always possible that there is something deep and subtle
> inside the CYGWIN DLL happening. (But I doubt it.)
Or may be in my environment. In another reply I was told that sometimes 
antivirus programs can cause similar behavior. I will test my scripts on 
another Win7 machines.
>


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

- Raw text -