public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Peter Rosin <peda@lysator.liu.se>
To: cygwin@cygwin.com
Subject: Re: Memory leak in select
Date: Mon, 18 Apr 2011 19:35:00 -0000	[thread overview]
Message-ID: <4DAC8F96.3080808@lysator.liu.se> (raw)
In-Reply-To: <20110418152801.GA11182@ednor.casa.cgf.cx>

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

  reply	other threads:[~2011-04-18 19:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-18 13:57 Peter Rosin
2011-04-18 15:03 ` Peter Rosin
2011-04-18 15:11   ` Peter Rosin
2011-04-18 15:40     ` Christopher Faylor
2011-04-18 15:54       ` Christopher Faylor
2011-04-18 19:35         ` Peter Rosin [this message]
2011-04-19 23:30           ` Peter Rosin
2011-04-20  5:16             ` Christopher Faylor
2011-04-20 12:08               ` Peter Rosin
2011-04-20 13:49               ` Thomas Stalder
2011-04-20 13:59                 ` Corinna Vinschen
2011-04-20 15:23                   ` Thomas Stalder
2011-04-19  7:53       ` Peter Rosin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DAC8F96.3080808@lysator.liu.se \
    --to=peda@lysator.liu.se \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).