X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4DACBCBE.1010003@lysator.liu.se>
Date: Tue, 19 Apr 2011 00:35:42 +0200
From: Peter Rosin <peda AT lysator DOT liu DOT se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Memory leak in select
References: <4DAC23E3 DOT 2020005 AT lysator DOT liu DOT se> <4DAC2D35 DOT 5070106 AT lysator DOT liu DOT se> <4DAC4B6A DOT 50101 AT lysator DOT liu DOT se> <20110418152441 DOT GA12913 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20110418152441.GA12913@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

Den 2011-04-18 17:24 skrev Christopher Faylor:
> On Mon, Apr 18, 2011 at 04:32:10PM +0200, Peter Rosin wrote:
>> Den 2011-04-18 14:23 skrev Peter Rosin:
>>> Den 2011-04-18 13:43 skrev Peter Rosin:
>>>> Hi!
>>>>
>>>> Using the following STC, I'm seeing what appears to be a memory
>>>> leak in select(2).
>>>>
>>> ----------------8<---(selectleak.c)---------
>>> #include <sys/time.h>
>>> #include <fcntl.h>
>>>
>>> int
>>> main(void)
>>> {
>>> 	fd_set fdset;
>>>
>>> 	long flags = fcntl(0, F_GETFL);
>>> 	fcntl(0, F_SETFL, flags | O_NONBLOCK);
>>>
>>> 	for (;;) {
>>> 		int res;
>>> 		char buf[20];
>>>
>>> 		FD_ZERO(&fdset);
>>> 		FD_SET(0, &fdset);
>>> 		res = select(1, &fdset, NULL, NULL, NULL);
>>> 		if (!res)
>>> 			continue;
>>> 		if (res < 0)
>>> 			return 1;
>>> 		res = read(0, buf, sizeof(buf));
>>> 		if (!res)
>>> 			break;
>>> 		if (res < 0)
>>> 			return 1;
>>> 	}
>>>
>>> 	return 0;
>>> }
>>> ----------------8<--------------------------
>>
>> Ok, I'm taking a wild swing at this, and my guess is that the call
>> sel.cleanup () in cygwin_select prematurely zeros out the cleanup
>> member of the select_record. The call to sel.poll () then adds
>> "stuff" to the select_record that really should have been cleaned
>> up, but isn't since cleanup has already been executed and then
>> zapped (by select_stuff::cleanup).
>>
>> But what do I know?
> 
> How does sel.poll add "stuff" that should be cleaned up?  That function
> only looks for bits to set.

I added syscall to the strace mask and that places the leak in read(2)
instead. But as stated previously, just look at the symptoms instead and
ignore my finger-pointing.

(I was fooled by the fact that the leak was after the sel.cleanup call,
but my limited experience with strace made me miss the fact that read(2)
was entered before the leak. So, I mistakedly placed the leak in the only
part left in cygwin_select, namely sel.poll)

Cheers,
Peter

--
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