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