zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-users@zsh.org
Subject: Re: File descriptor leakage?
Date: Mon, 29 Sep 2014 11:59:01 +0100	[thread overview]
Message-ID: <20140929115901.255bacb9@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <140928230710.ZM5202@torch.brasslantern.com>

On Sun, 28 Sep 2014 23:07:10 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 29, 11:53am, lilydjwg wrote:
> }
> } I discover that my zsh keeps a file descriptor to a deleted
> } ".histfile.new" file:
> 
> This is the file created when the HIST_SAVE_BY_COPY option is set, which
> is then renamed to the name given by $HISTFILE after being written.  I
> don't know of any reason the behavior for this would have changed from
> 5.0.5 to 5.0.6, but it's possible that workers/33116 is related.

The option is on by default, so a lot of people ought to be seeing
this.  It looks like either it's system-specific or maybe to do with
some hairy history option combination --- there are plenty of those,
though it's not obvious why they'd have an effect here.

> There is an assumption that
> 
>   fd = open(file, O_WRONLY, 0600);
>   out = fdopen(fd, "w");
>   fclose(out);
> 
> will close fd, but that assumption has been there for as long as the
> HIST_SAVE_BY_COPY option has existed.

Fairly easy to add a "close(fileno(out));" and see if it goes away.
That would be after the fclose() currently at line 2682 of Src/hist.c.

I note we don't handle the case where the open() succeeded but the
fdopen() failed in this case (around line 2595) unlike other cases
(around 2822 and 2876).  This would probably be good practice anyway.

lilydjwg <lilydjwg@gmail.com> wrote:
> Hi, I did a git bisect and found this commit is the first bad one:
> 979f72199f3d3e98b1f6c712fa26f731dac2cb51

(...finds out about "git show" again...)

Hmm, that's to do with file locking.  That might suggest some path
through the code where this isn't handled that neither Bart nor I have
spotted yet.

diff --git a/Src/hist.c b/Src/hist.c
index d29a65a..4660fd0 100644
--- a/Src/hist.c
+++ b/Src/hist.c
@@ -2593,7 +2593,12 @@ savehistfile(char *fn, int err, int writeflags)
 		out = NULL;
 	    } else {
 		int fd = open(tmpfile, O_CREAT | O_WRONLY | O_EXCL, 0600);
-		out = fd >= 0 ? fdopen(fd, "w") : NULL;
+		if (fd >=0) {
+		    out = fdopen(fd, "w");
+		    if (!out)
+			close(fd);
+		} else
+		    out = NULL;
 	    }
 
 #ifdef HAVE_FCHMOD

pws


  parent reply	other threads:[~2014-09-29 10:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29  3:53 lilydjwg
2014-09-29  6:07 ` Bart Schaefer
2014-09-29 10:47   ` lilydjwg
2014-09-29 10:59   ` Peter Stephenson [this message]
2014-09-29 13:58     ` lilydjwg
2014-09-29 14:03       ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140929115901.255bacb9@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).