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: <4DAC8F96.3080808@lysator.liu.se>
Date: Mon, 18 Apr 2011 21:23:02 +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> <20110418152801 DOT GA11182 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20110418152801.GA11182@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:28 skrev Christopher Faylor:
> 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.

I shouldn't have included the strace, and I shouldn't have guessed about
the cause of the problem without verifying my claims. Sorry about that.
But for the record the included strace snippet is reoccurring like that
many many times (the address of the allocation that isn't freed is
moving).  Further evidence; the STC leaks 1 MB every 3 seconds on my
computer, that just can't be right.

I have probably just read the code wrong, and I did say it was a wild
swing. So please ignore my feeble guesses as to what the cause might be
and take it from the symptoms instead. You have been provided with a STC,
and I have certainly done a fair share in cornering the bug my coming up
with that STC. You should be aware that the STC was NOT the first thing
I tried and it was NOT the first thing I thought was wrong when I
observed a leak in one of my "real" programs.

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

Have you tried to invoke the program like I wrote in the original message
(i.e. cat /dev/zero | ./selectleak) before making sweeping statements like
that?

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