This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Memory leak in select

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]