From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9731 invoked from network); 5 Sep 2020 09:25:09 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 5 Sep 2020 09:25:09 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1599297909; b=lyt9A+tVIqsifmtGW84tn1z9gL2DEfV6SrOlJ7mwMokz2ixM8lV5bZeZBbmSJQGWYmqI54JwYK uBpcR5r64+23v3zLp00XxBpSanArRsmqvs2BoSdsBueKsaVOGR+VvIy19na/fYWk4nJjySUUxp NbmW06X63omB2CnYOa2yJhVHMudYCJJPEThT/yWBU15ffj90kugukXJHdTutmnzf61Usr6D+FZ eBvfDhch86nHWAXZHz8wX+l0C5oiixaK6x0wlLd49Y8D6ek9lC6DG08VWQ7bpESNRvcRnOsK9e ic5cgBS2F2C9pNWac6krL1E7tO9jrjk4hrHefeuHu3hUAQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lf1-f54.google.com) smtp.remote-ip=209.85.167.54; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1599297909; bh=NnsIPkALYIyEuB40CFss1YlQvElIUE2czauabTS1Owg=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=kVd55cBJt1dbzlxlUZuAkMi31OivD/4cRwN5P36z+h3XH43nQ/KUJW/r8P4cGifOOvRjDQXv7j /YTR8f93D8OFNb2JL2MG6d8xFkntEi88o7bwAUme/lqmGZUUA1lo2rHRD8xBm9DxY+iwVTp88o AeWkNvaQeLGQif0DIqZttO91L6uTaPjozg0J4pdA+9lE0fSSIIMnT6A/kxad+xq2PuFcc5G0XG Jffd+VRqkvfZ3Sp8DjN21Xerw2RaqrAl7mdjREFf+ddzE9YA4ADw6EKNkFAOk0nBw+As15KHHc QuReVYOhS/Y8IzVkptDox7E8Hc5Z5H5cBBzr+/ty4HhD0A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=31CPVXu5HZh6TYpfMBZV1FNaRPC92IKQGVqvuRgwZqU=; b=Po2J+WSTnb18nN1XHXD66cJ1zg tegwelkHiUJy86aoa9/pL0wLG//DLmdkaLoZvwDcjJZQBxtAQQHacilbec9/Fy7FmNqVFvoADelBS Gf5WfISdsVPznX1356duwXzWmJ+pqg743q8xeu4+SCu4SMEs6O73gD7Feyi+k4tju0a5IZVLvOrjH UtBPbFLKPoPIOtFsCfYpY0SEV1h+K1mCns/qFAaFAhGCprTgqFg/XdMu6gJqVv2RX+8t6pbEnjcDF WPgVkapq6HX31OhoKa0Xq2ePf3s9slh2eRMQu8kFOpK1by9SjA4EHqP8x68CWeGAbjE2JT+qDaKFD E+HDTIwg==; Received: from authenticated user by zero.zsh.org with local id 1kEURX-0006sx-4Y; Sat, 05 Sep 2020 09:25:07 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lf1-f54.google.com) smtp.remote-ip=209.85.167.54; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-lf1-f54.google.com ([209.85.167.54]:44426) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kEURB-0006iu-5F; Sat, 05 Sep 2020 09:24:45 +0000 Received: by mail-lf1-f54.google.com with SMTP id d15so4197485lfq.11 for ; Sat, 05 Sep 2020 02:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=31CPVXu5HZh6TYpfMBZV1FNaRPC92IKQGVqvuRgwZqU=; b=lMTMq0OyxXIRjYerF33IMjInKQB4hUkTQrP95x6vfq1p6I/pgO2ZAdqUbqtvyGLvrj GuaP5rdEShjLMTR1xG1bgDQBb3lUmqwpDhfxg2vsGwAWzAvcwrwhtQG03w74oxjeXfaD sx2va8YfEQtXFTpm94J9oME8HaBUmOZJ/vxTp7nn/dwMtB4TamjTmkweD/MAEqShqVOL hCWLInUjDxnspdEdWkW+cS7k9WxkiqYLAWTxN2kIWQobsb6GEwe2hn11hbMmpS/vPvAc IKkpGoqKXdSPjQha1MAFNMK9PBlvNkcKrMKpqu9pCYtYTiz91a6fuVjXeqok2hgLPQ+B F45A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=31CPVXu5HZh6TYpfMBZV1FNaRPC92IKQGVqvuRgwZqU=; b=qhErCzFoYMvQ4tvpEAp0m6eZ6Uvq/moa4eWZOEq2IOtHaShAAaY7ZLHYUPSrP9NnUC a/gGyUXj9S2UD1QPwMP6LdQXKYyjU6jX/n5lUTmET//R9tz+7FKQKTTTVuollYnuenvE ukMZz/iTVfphBm4qR52F0gWTGAnvI7dfOFjZMQ6KwaBwAqNNfcqgLM28Ts9FQcYAUFd0 njPGeSJE3FjFdDS4DpKDePxfN0s2se9cs4hP//1gPao/WQV8KjK4nAsc1jKHYghpCSUY N1vOx6YGe0aVPCan781kBPCMSDU5Mos5y1nvvObk86b1NGPFuhiVRg0bD20zsrzWw75k 0yhQ== X-Gm-Message-State: AOAM530qFYnQFv+twYolXD4myVUcQPx+VV4QxB4UJ/bYcUSQYP2su/VB AhTLOOzm7IwhZYpTSZ3v6fhWjsWIb2YmGLoXEXtlZDQ1Xzw= X-Google-Smtp-Source: ABdhPJw1GmFm5jmexOJsc8UrwrgpkuLsVQ9D2FgbfbvdFQ0gz0/sqJDEaEknewcBqxBhbIbMgoSVV8nKuxCIDc+6Z6o= X-Received: by 2002:a19:df55:: with SMTP id q21mr5751325lfj.47.1599297882986; Sat, 05 Sep 2020 02:24:42 -0700 (PDT) MIME-Version: 1.0 References: <309829031.4459446.1587391766024@mail2.virginmedia.com> <20200503000658.6fddb904@tarpaulin.shahaf.local2> <20200503210618.5c639014@tarpaulin.shahaf.local2> <505277422.148264.1588581302888@mail2.virginmedia.com> <20200505000331.59294412@tarpaulin.shahaf.local2> <600054363.204367.1588697277901@mail2.virginmedia.com> <20200904194856.0e115c95@tarpaulin.shahaf.local2> In-Reply-To: From: =?UTF-8?Q?Timoth=C3=A9e_Mazzucotelli?= Date: Sat, 5 Sep 2020 11:24:32 +0200 Message-ID: Subject: Re: Feature request: ZSH_XTRACEFD variable To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="00000000000034a08105ae8d8e16" X-Seq: 47362 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --00000000000034a08105ae8d8e16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you very much Daniel for this great explanation on what leaking a FILE (or a fd) means. It's much clearer now. >From what I understand, the code for the ZSH_XTRACEFD feature will then not leak any file descriptor itself. Based on the man pages: > The *fdopen*() function associates a stream with the existing file descriptor, *fd*. [...] > The file descriptor is not dup'ed, and will be closed when the stream created by *fdopen*() is closed. The user is the one creating the file descriptor initially, and all Zsh does is assigning it to the xtrerr variable. > xtrerr =3D fdopen(fd, "w"); Zsh should not close the file descriptor itself. As stated previously, it should be the user's choice and responsibility to close the file descriptors they have opened. If, however, the stream associated to the fd by fdopen allocates memory, then not closing that stream and assigning another value to xtrerr would indeed cause a memory leak. In that case, and now that I understand Bart's answer under the light of your explanation, we could fdopen a duplicate of the fd instead, so we can close both the duplicated fd and its associated stream, fixing the memory leak. We could use the valgrind test suite to make sure there's a memory leak or not, unfortunately I did not manage to have it working on my computer (there were a lot of reported leaks when there should not have been any, see previous messages). Timoth=C3=A9e On Fri, Sep 4, 2020 at 9:54 PM Bart Schaefer wrote: > On Fri, Sep 4, 2020 at 12:49 PM Daniel Shahaf > wrote: > > > > zsh: cannot moved fd 3: too many open files > > > > P.S. The quoted error message is ungrammatical. > > That is supposed to say "cannot movefd fd 3" ... movefd being the name > of the function ... someone has done a spell-checking pass over the > error messages and fixed a "mistake" that wasn't actually a mistake? > > --00000000000034a08105ae8d8e16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much Daniel for this great explanation=
on what leaking a FILE (or a fd) means. It's much clearer no= w.

From what I understand, the code for the ZSH_XT= RACEFD feature
will then not leak any file descriptor itself.

Based on the man pages:

>= The fdopen() function associates a stream with the existing file de= scriptor, fd. [...]
> The file descriptor is not dup= 9;ed, and will be closed when the stream created by fdopen() is closed.
<= div>
The user is the one creating the file descriptor initial= ly,
and all Zsh does is assigning it to the xtrerr variable.

> xtrerr =3D= fdopen(fd, = "w");
<= div>
Zsh should not close the file descriptor itsel= f.
As stated previo= usly, it should be the user's choice and responsibility
to close the file descriptors they= have opened.

If, however, the stream associated t= o the fd by fdopen allocates memory,
then not closing that stream= and assigning another value to xtrerr would indeed cause a memory leak.
In that case, and now that I understand Bart's answer under the= light of your explanation,
we could fdopen a duplicate of the fd= instead,
so we can close both the duplicated fd and its associat= ed stream, fixing the memory leak.

We could use th= e valgrind test suite to make sure there's a memory leak or not,
<= div>unfortunately I did not manage to have it working on my computer
<= div>(there were a lot of reported leaks when there should not have been any= , see previous messages).

Timoth=C3=A9e
<= /div>
O= n Fri, Sep 4, 2020 at 9:54 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
On Fri, Sep 4, 2020 at 12:49 PM = Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> zsh: cannot moved fd 3: too many open files
>
> P.S.=C2=A0 The quoted error message is ungrammatical.

That is supposed to say "cannot movefd fd 3" ... movefd being the= name
of the function ... someone has done a spell-checking pass over the
error messages and fixed a "mistake" that wasn't actually a m= istake?

--00000000000034a08105ae8d8e16--