From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17233 invoked from network); 22 Sep 2009 13:40:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 22 Sep 2009 13:40:28 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 20955 invoked from network); 22 Sep 2009 13:40:23 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 22 Sep 2009 13:40:23 -0000 Received: (qmail 15059 invoked by alias); 22 Sep 2009 13:40:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27285 Received: (qmail 15046 invoked from network); 22 Sep 2009 13:40:19 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 22 Sep 2009 13:40:19 -0000 Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by bifrost.dotsrc.org (Postfix) with ESMTP id C2E3C801E2BF for ; Tue, 22 Sep 2009 15:40:12 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.222.107]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KQD003G8KMX4690@vms173013.mailsrvcs.net> for zsh-workers@sunsite.dk; Tue, 22 Sep 2009 08:40:10 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n8MDe77q005885 for ; Tue, 22 Sep 2009 06:40:08 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n8MDe7Ib005884 for zsh-workers@sunsite.dk; Tue, 22 Sep 2009 06:40:07 -0700 From: Bart Schaefer Message-id: <090922064007.ZM5883@torch.brasslantern.com> Date: Tue, 22 Sep 2009 06:40:07 -0700 In-reply-to: <20090922100019.3c302758@news01> Comments: In reply to Peter Stephenson "Re: latest from CVS segfaults when FD ulimit is set too low" (Sep 22, 10:00am) References: <87iqfgwplu.fsf@meyering.net> <20090921214528.7c7b412c@pws-pc> <20090922100019.3c302758@news01> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: latest from CVS segfaults when FD ulimit is set too low MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9821/Tue Sep 22 01:48:15 2009 on bifrost X-Virus-Status: Clean On Sep 22, 10:00am, Peter Stephenson wrote: } Subject: Re: latest from CVS segfaults when FD ulimit is set too low } } I don't think it's safe to leave the unmoved fd open, after all, } in too many places that will leak. In some places we need the } original fd, but in those places if the move fails the code will } fail catastrophically---for example in zle and completion we attempt } to move fd 0 temporarily and then move it back; if that failed we } shouldn't attempt the operation. I haven't done that much surgery, so } I've restored the original zclose() here for now. Perhaps instead of an unconditional close, movefd() should do if (fe != -1 || fd > 2) zclose(fd); so we never actually lose stdin/out/err but other leaks are plugged. I haven't studied the ramifications of this.