From: Bart Schaefer <schaefer@brasslantern.com>
To: Vincent Lefevre <vincent@vinc17.net>, zsh-workers@zsh.org
Subject: Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze
Date: Fri, 20 Dec 2013 19:42:23 -0800 [thread overview]
Message-ID: <131220194223.ZM29152@torch.brasslantern.com> (raw)
In-Reply-To: <131220181950.ZM15385@torch.brasslantern.com>
On Dec 20, 6:19pm, Bart Schaefer wrote:
}
} + * 31549: Src/exec,c, Src/zsh.h: replace ad-hoc subsh_close file
} + descriptor for pipes with new addfilelist() job-based mechanism.
Yep, that's the one.
I compiled commit 709dbbbda82efde2020d9d67a19687c101b91570 and was
able to reproduce the problem. The immediately preceding commit
39ab9952e8255cb99e9c0abcc8bbec43158a55d7 does not show the bug.
Non-interactive shells also do not show the bug, which may be why
"make check" didn't flag anything.
The problem seems to be with this hunk specifically:
@@ -1744,8 +1742,6 @@ execpline2(Estate state, wordcode pcode,
execpline2(state, *state->pc++, how, pipes[0], output, last1);
list_pipe = old_list_pipe;
cmdpop();
- zclose(pipes[0]);
- subsh_close = -1;
}
}
The problem is that pipes[0] isn't always added to the list of files
for the job; sometimes it really does need to be closed there.
diff --git a/Src/exec.c b/Src/exec.c
index dccdc2b..4480033 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1691,6 +1691,7 @@ execpline2(Estate state, wordcode pcode,
execcmd(state, input, output, how, last1 ? 1 : 2);
else {
int old_list_pipe = list_pipe;
+ int subsh_close = -1;
Wordcode next = state->pc + (*state->pc), pc;
wordcode code;
@@ -1738,6 +1739,7 @@ execpline2(Estate state, wordcode pcode,
} else {
/* otherwise just do the pipeline normally. */
addfilelist(NULL, pipes[0]);
+ subsh_close = pipes[0];
execcmd(state, input, pipes[1], how, 0);
}
zclose(pipes[1]);
@@ -1750,6 +1752,8 @@ execpline2(Estate state, wordcode pcode,
execpline2(state, *state->pc++, how, pipes[0], output, last1);
list_pipe = old_list_pipe;
cmdpop();
+ if (subsh_close != pipes[0])
+ zclose(pipes[0]);
}
}
next prev parent reply other threads:[~2013-12-21 3:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 19:24 Axel Beckert
2013-12-20 20:27 ` Bart Schaefer
2013-12-20 20:49 ` Axel Beckert
2013-12-20 23:51 ` Vincent Lefevre
2013-12-20 23:59 ` Vincent Lefevre
2013-12-21 0:12 ` Vincent Lefevre
2013-12-21 2:19 ` Bart Schaefer
2013-12-21 3:42 ` Bart Schaefer [this message]
2013-12-21 7:16 ` Bart Schaefer
2013-12-21 18:08 ` Peter Stephenson
2013-12-21 20:57 ` Bart Schaefer
2013-12-21 22:34 ` Peter Stephenson
2013-12-22 1:34 ` Bart Schaefer
2013-12-23 2:06 ` (potential regression in 5.0.3) Paul Ackersviller
2013-12-23 5:47 ` Bart Schaefer
2014-01-02 18:06 ` Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze Peter Stephenson
2014-01-02 20:40 ` Bart Schaefer
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=131220194223.ZM29152@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=vincent@vinc17.net \
--cc=zsh-workers@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).