Re: Memory leak in select

[Christopher Faylor <cgf-use-the-mailinglist-please 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