cat /dev/zero | dd > /test breaks Fish

[jos128]

Please tell us which fish version you are using...

user@host fish$> echo $version; echo $TERM; uname -vosr
3.1.0
xterm-256color
Linux 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 GNU/Linux

Edit:

Problem persists on Fish 3.1.2 installed via PPA.

Please tell us if you tried fish without third-party customizations...

Yes, the problem still persists with vanilla Fish.

Tell us how to reproduce the problem.

1. Gnome Terminal Bash as "base shell":

user@host bash$> fish
user@host fish$> cat /dev/zero | dd > /test
<W> fish: An error occurred while redirecting file '/test'
open: Permission denied
user@host fish$>

• Fish becomes unresponsive; not recovering.

2. Gnome Terminal Fish as "base shell"

user@host fish$> cat /dev/zero | dd > /test
<W> fish: An error occurred while redirecting file '/test'
open: Permission denied
user@host fish$>

• On keystroke the Gnome Terminal Window closes/crashes.

Notes

• Bash seems to handle this.

user@host bash$> cat /dev/zero | dd > /test
bash: /test: Permission denied
user@host bash$>
user@host bash$>

• The problem seem to be with the pipe. This works fine:

user@host fish$> cat /dev/zero > /test
<W> fish: An error occurred while redirecting file '/test'
open: Permission denied
user@host fish$>

• This crashes the terminal window:

user@host fish$> cat /dev/zero | cat > /test
<W> fish: An error occurred while redirecting file '/test'
open: Permission denied
user@host fish$>

[faho]

Please upgrade to fish 3.1.2, there are a few bug fixes in that that might apply here. jos128 <notifications@github.com> schrieb am Mo., 25. Mai 2020, 13:01:

…

Please tell us which fish version you are using... ***@***.*** fish$> echo $version; echo $TERM; uname -vosr3.1.0xterm-256colorLinux 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 GNU/Linux Please tell us if you tried fish without third-party customizations... Yes, the problem still persists with vanilla Fish. Tell us how to reproduce the problem. 1. Gnome Terminal Bash as "base shell": ***@***.*** bash$> ***@***.*** fish$> cat /dev/zero | dd > /test<W> fish: An error occurred while redirecting file '/test'open: Permission ***@***.*** fish$> - Fish becomes unresponsive; seem to not recover. 2. Gnome Terminal Fish as "base shell" ***@***.*** fish$> cat /dev/zero | dd > /test<W> fish: An error occurred while redirecting file '/test'open: Permission ***@***.*** fish$> - On keystroke the Gnome Terminal Window closes/crashes. Notes - Bash seems to handle this. ***@***.*** bash$> cat /dev/zero | dd > /testbash: /test: Permission ***@***.*** ***@***.*** bash$> - The problem seem to be with the pipe. This works fine: ***@***.*** fish$> cat /dev/zero > /test<W> fish: An error occurred while redirecting file '/test'open: Permission ***@***.*** fish$> - This crashes the terminal window: ***@***.*** fish$> cat /dev/zero | cat > /test<W> fish: An error occurred while redirecting file '/test'open: Permission ***@***.*** fish$> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7038>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHR6VYONS3CPHFYUZ33PJTRTJFZDANCNFSM4NJNYQMA> .

[jos128]

I upgraded via PPA, the problem unfortunately persists:

user@host fish$> echo $version
3.1.2
user@host fish$> cat /dev/zero | cat > /test
<W> fish: An error occurred while redirecting file '/test'
open: Permission denied
user@host fish$>

• Gnome Terminal window crashes on keystroke.
• If run as subshell in bash, it does not react to CTRL + C, but terminates on kill $PID with the PID of the cat <defunct> process or fish. Maybe that helps.

[zanchey]

Yes, I can reproduce this on cbf5362.

[zanchey]

fish doesn't actually crash, it reads EOF from stdin and exits normally.

[krobelus]

When running this in a fish inside another shell, it does not exit or react to Ctrl-C as you observed.
Fish keeps receiving SIGTTIN ("Background process attempting read.") so quickly that it maxes out one CPU.

[jos128]

The frozen fish shell (in bash) goes 100% CPU on any keystroke. Also stays at 100% CPU usage.

[krobelus]

Bisects to d62576c.

For some reason, after running cat /dev/null | cat > /test, fish is no longer the process group leader. Simple fix: make fish the process group leader after open fails. I'm not yet sure where this should go.

diff --git a/src/io.cpp b/src/io.cpp
index 081354b1b..4045beee7 100644
--- a/src/io.cpp
+++ b/src/io.cpp
@@ -254,2 +254,4 @@ bool io_chain_t::append_from_specs(const redirection_spec_list_t &specs, const w
                         if (should_flog(warning)) wperror(L"open");
+                        pid_t shell_pgid = getpgrp();
+                        tcsetpgrp(STDIN_FILENO, shell_pgid);
                     }

[mqudsi]

Thanks for bisecting that, @krobelus.

Currently if setup_child_process fails, then all bets are off regarding both redirections and process groups because they may have been changed before the file descriptor was resolved (or, as in this case, failed to resolve). Reasserting ownership of the terminal input could be performed there so that it's not undetermined and that should propagate to all the other edge cases.

More correctly though, I think there needs to be some feedback mechanism for dup2_list_t that lets the code be more deterministic by clearly indicating at which point in the chain the failure occurred. The old io_chain_t approach was fully integrated in handle_child_io and I believe that prevented the "all bets are off" result.

I've mentioned this in passing before, but imho all the pgroup checks and sets that we have all over the codebase is something we should be refactoring to cut down on. Context switches between user and kernel modes are getting more and more expensive with each speculative execution mitigation on a monthly basis and they make reasoning about groups really hard.

[mqudsi]

I "fixed" this in bc756a9 but with the caveat that fish's handling of pipelines broken by failed job executions is now different. In particular, a bad redirection mid-pipeline results in the job continuing to run but with the broken fd replaced with a closed fd. This gives fish a chance to recover after having passed control of the terminal to another process.

To illustrate with an example, the original bug reported in this PR now exhibits the following behavior:

mqudsi@ZBOOK ~/r/fish-shell> cat /dev/zero | cat > /test
warning: An error occurred while redirecting file '/test'
open: Permission denied
cat: standard output: Bad file descriptor

(Personally, I think this is more correct than the previous model even setting the regression aside but I will bat-signal @ridiculousfish for his seal of approval. This does also eliminate an entire class of bugs resulting from aborted job cleanup.)