zsh usually hangs when using command substitution with pipes

[bk2204]

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.17763.316]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

1. Install Debian.
2. sudo apt-get update
3. sudo apt-get -y install zsh
4. zsh -c 'DATA=$(echo abc | sed -e "s/b/d/")'

zsh hangs. Occasionally it will complete, but most of the time it doesn't.

If a command substitution with a pipe appears in a zsh startup script (e.g. .zshenv) and zsh is the user's shell in /etc/passwd, starting the WSL instance will hang and the instance will have to be reset.

This behavior doesn't occur when using mksh, bash, or dash in place of zsh.

zsh always succeeds when run under strace, however.

• What's wrong / what should be happening instead:

zsh shouldn't hang in this case.

This looks potentially related to #1973, but that issue seems to have been fixed already. This may also be the same issue as #3392, but I'm unsure as I can't read the logs.

Also, as a note, this did work fine in 1803, but does not in 1809 (i.e., this is a regression).

• Strace of the failing command, if applicable:

I haven't provided an strace because this doesn't fail when traced and I didn't think that would be useful. If you want one anyway, please let me know, and I'll provide one.

[craigloewen-msft]

Hi @bk2204

I'm not able to reproduce this behavior in build 18837. So it looks like the problem may either be intermittent or may be fixed already.

@bk2204 , if you try and reproduce this problem inside of another distro (like Ubuntu) do you get the same behaviour?

[bk2204]

I'm not able to reproduce this behavior in build 18837. So it looks like the problem may either be intermittent or may be fixed already.

If so, that would be good news.

I should point out that this is a VM, running on VMWare Fusion on macOS Mojave. So if there's a potential performance issue involved, that could be a possibility.

I'm unfortunately unable to test out a pre-release build, since this is a VM I use for work (and therefore it needs to be kept functional).

@bk2204 , if you try and reproduce this problem inside of another distro (like Ubuntu) do you get the same behaviour?

I do indeed see this on Ubuntu. Like on Debian, it doesn't happen every time, but most times it does. Like on Debian, it doesn't fail under strace.

[therealkenc]

I'm not able to reproduce this behavior in build 18837

WAG this might be related to Rick Grimes problem. The OP smells like #3129 which has a similar repro but with Busybox ash. Zombies would explain the sporadic nature since it depends on how fast the piped process dies. But dead zombies wouldn't explain the proposition this was somehow a regression since working in 1803 that somehow got broken in 1809 and then made a miraculous recovery post-1809 Insiders.

[bk2204]

I do have a problem with zombie processes sticking around when this occurs..

I know this worked in 1803 because my zsh configuration has extensive use of this construct and starting a WSL session with /bin/zsh as my default shell didn't hang then like it does in 1809.

In my shell configuration (but not with the reduced testcase), I also see significant CPU usage from one of the zsh child processes, and ps axf shows a zsh process continually in the R (running) state. My VM becomes sluggish and my Mac's CPU fan cranks up.

Finally, one additional note that may or may not be interesting: this occurs even if the command substitution calls a shell function and that shell function has a pipe in it. I don't suppose that makes much of a difference in how zsh invokes things, but I thought I'd mention it in case it's helpful.

[xarthurx]

Same issue here.
CPU 100% for several Zsh child process, have to kill it manually.

[bk2204]

This appears to be fixed in 1903, where my old shell configuration seem to work fine. There's no longer a hang when starting zsh or using my reproduction test case.

I'm going to close this issue since it seems to be fixed.

[therealkenc]

Thanks for the confirm. This was almost certainly variation #3129.