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
