Date: Mon, 18 Apr 2011 11:28:01 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Memory leak in select
Message-ID: <20110418152801.GA11182@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110418152441.GA12913@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Mon, Apr 18, 2011 at 11:24:41AM -0400, Christopher Faylor wrote:
>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.

Also since select() can allocate a persistent thread you can't expect that
the number of allocs will always be equal to the number of frees.  There
could be some allocation of space for thread bookkeeping.

cgf

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