From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2096 invoked by alias); 24 Sep 2015 03:12:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36605 Received: (qmail 11006 invoked from network); 24 Sep 2015 03:12:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=EHEWd+D7/FNo1JNHmfXZHP36CExbJqULUlNcbhkTB+I=; b=BSbiIWZOX3q6l3Dx1fwjboyr/2de/7AjhjzfFutZbQhliuDtqrPowpuxS/KShlHrLg svEi021e3wZEbBl2t2Ub3TcR9Zvw5Jwt++nLr3N0cbiJJtSh2T41YYBOgrYiCcoe/H8R BtHxXrIB+KQDU3u2px/v+zhkyQXMfFwRhDz94g/hvBC9R96bLXzHPghHGqWZr9wqbKz/ rsNmUX1yb5ukZzYzqDFWPn9+VqXjKI9RqVOmIj5D1V6FfvnG7xoQqKvt19rP2oJiEHgL vv8EBLFb5UWp/UzYbSoGTknpHr2FqQaGmmOHu0F69nKvzceD5asfDUutw4Sb7Lnnkqj5 9kiA== X-Gm-Message-State: ALoCoQlALDbPm1zImQJjOd0tnltkBmDHSm/XH6F6ZCBGCVD+V9JxUX1wA0RtB08HFBAf603NtuEL X-Received: by 10.182.65.164 with SMTP id y4mr20952170obs.65.1443064323635; Wed, 23 Sep 2015 20:12:03 -0700 (PDT) From: Bart Schaefer Message-Id: <150923201201.ZM32285@torch.brasslantern.com> Date: Wed, 23 Sep 2015 20:12:01 -0700 In-Reply-To: <1443045290-26615-1-git-send-email-mikachu@gmail.com> Comments: In reply to Mikael Magnusson "PATCH: Fix leak during Y shortcircuit glob qualifier" (Sep 23, 11:54pm) References: <1443045290-26615-1-git-send-email-mikachu@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Mikael Magnusson , zsh-workers@zsh.org Subject: Re: PATCH: Fix leak during Y shortcircuit glob qualifier MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 23, 11:54pm, Mikael Magnusson wrote: } Subject: PATCH: Fix leak during Y shortcircuit glob qualifier } } The closedir(lock) is the leak I actually did see in usage, I have no } idea if the other part is needed/harmful though. I'll commit just the } closedir if nobody has any opinions. Since scanner() is being called recursively, it's not clear that the recursive call won't have already done an equivalent restoredir() in the first two "return" cases -- but I do suspect it's needed in the case where the closedir(lock) plugs a leak. Is the current directory munged in the situation where you found a leak?