From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8538 invoked from network); 14 Apr 2008 14:42:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Apr 2008 14:42:38 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 62893 invoked from network); 14 Apr 2008 14:42:33 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Apr 2008 14:42:33 -0000 Received: (qmail 8598 invoked by alias); 14 Apr 2008 14:42:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24816 Received: (qmail 8579 invoked from network); 14 Apr 2008 14:42:28 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Apr 2008 14:42:28 -0000 Received: from prunille.vinc17.org (vinc17.pck.nerim.net [213.41.242.187]) by bifrost.dotsrc.org (Postfix) with ESMTP id 321E98043AC7 for ; Mon, 14 Apr 2008 16:42:19 +0200 (CEST) Received: by prunille.vinc17.org (Postfix, from userid 501) id C83C0218D99A; Mon, 14 Apr 2008 16:42:19 +0200 (CEST) Date: Mon, 14 Apr 2008 16:42:19 +0200 From: Vincent Lefevre To: zsh-workers@sunsite.dk Subject: Re: Possible memory leak in hist.c Message-ID: <20080414144219.GU1223@prunille.vinc17.org> Mail-Followup-To: zsh-workers@sunsite.dk References: <20080414132735.GT1223@prunille.vinc17.org> <200804141334.m3EDYRJj006753@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200804141334.m3EDYRJj006753@news01.csr.com> X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.17-vl-r21552 (2008-03-11) X-Virus-Scanned: ClamAV 0.91.2/6759/Mon Apr 14 14:56:05 2008 on bifrost X-Virus-Status: Clean On 2008-04-14 14:34:27 +0100, Peter Stephenson wrote: > It does look suspicious. However, we're currently using tmpfile to > indicate whether we should be reporting an error about the temporary > file, so without more work it looks like we can't actually remove the > early frees. If fact there are two "free(tmpfile);": one of them is followed by a "err = 0" and for the other one, ret remains >= 0, so that if tmpfile is freed, then no more messages can be output. > They should certainly be setting tmpfile to NULL, though. This solution may be cleaner, though. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)