X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org X-Yahoo-SMTP: jenXL62swBAWhMTL3wnej93oaS0ClBQOAKs8jbEbx_o- Date: Tue, 19 Apr 2011 21:10:57 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Memory leak in select Message-ID: <20110420011057.GA453@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com 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> <4DAC8F96 DOT 3080808 AT lysator DOT liu DOT se> <4DADFF3A DOT 1060006 AT lysator DOT liu DOT se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DADFF3A.1060006@lysator.liu.se> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Tue, Apr 19, 2011 at 11:31:38PM +0200, Peter Rosin wrote: >Den 2011-04-18 21:23 skrev Peter Rosin: >> 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 >>>>>> #include >>>>>> >>>>>> 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. > >Back with a patch this time. Fixes it for me... > >Cheers, >Peter > >2011-04-19 Peter Rosin > > * select.cc (pipe_cleanup): Don't leak a select_pipe_info when a > thread turned out not to be needed. Makes sense. I've checked this in (with a different ChangeLog). Thanks for the patch. 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