From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23612 invoked by alias); 18 Apr 2011 22:36:02 -0000 Received: (qmail 23429 invoked by uid 22791); 18 Apr 2011 22:36:00 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.lysator.liu.se (HELO mail.lysator.liu.se) (130.236.254.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Apr 2011 22:35:46 +0000 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C9C7E40012 for ; Tue, 19 Apr 2011 00:35:44 +0200 (CEST) Received: from [192.168.0.33] (h57n3fls301o1095.telia.com [81.230.178.57]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 9D2DA40002 for ; Tue, 19 Apr 2011 00:35:44 +0200 (CEST) Message-ID: <4DACBCBE.1010003@lysator.liu.se> Date: Tue, 19 Apr 2011 07:53:00 -0000 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Memory leak in select References: <4DAC23E3.2020005@lysator.liu.se> <4DAC2D35.5070106@lysator.liu.se> <4DAC4B6A.50101@lysator.liu.se> <20110418152441.GA12913@ednor.casa.cgf.cx> In-Reply-To: <20110418152441.GA12913@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-04/txt/msg00266.txt.bz2 Den 2011-04-18 17:24 skrev Christopher Faylor: > 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 added syscall to the strace mask and that places the leak in read(2) instead. But as stated previously, just look at the symptoms instead and ignore my finger-pointing. (I was fooled by the fact that the leak was after the sel.cleanup call, but my limited experience with strace made me miss the fact that read(2) was entered before the leak. So, I mistakedly placed the leak in the only part left in cygwin_select, namely sel.poll) 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