[vim/vim] vim freezes if suspended with Ctrl-Z while running system command (Issue #10369)
Pavol Juhas
Steps to reproduce
- Start Vim in a Unix terminal using
vim --clean -i NONE -c "call system('sleep 10')" - Press
Ctrl-Z
The SIGTSTP signal is received by the sleep process, but not by Vim. Vim waits for the suspended sleep command to complete and is thus blocked. Typed keys appear on the screen, but don't do anything, pressing Ctrl-C or Ctrl-Z has no effect.
The only way of exiting that state is to open a new terminal and run pkill -CONT sleep, which will resume the sleep process and unblock Vim.
Bisection shows this behavior was introduced in v8.2.3941.
Expected behaviour
Vim is suspended together with the system command that was executing. The user is back at interactive terminal.
Version of Vim
8.2.4897
Environment
Debian GNU/Linux, xterm, zsh, but these should not matter.
The behavior appears at v8.2.3941.
cc: @dbivolaru
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dorian Bivolaru
Based on what I see on my box, this starts both a shell and the sleep command itself. The CTRL-Z suspends both the bash and the sleep instance but not vim.
$ ps aux | grep sleep
1234 vim --clean -i NONE -c call system('sleep 10')
1235 /bin/bash -c (sleep 10)>/tmp/vcHzT0f/0 2>&1
1236 sleep 10
The SIGCONT using the command you mentioned, only affects the child sleep process and the bash invocation stays suspended. The sleep process becomes defunct after the 10 seconds are gone.
To replicate fg/bg behavior, you need to send the SIGCONT to the process group, ie kill -CONT -1234 instead of kill -CONT -1236. Please take note of the minus sign in front of the PID.
To me it seems it works like intended. If you're in vim, CTRL-Z is taking out vim. If vim is executing an external command, CTLR-Z takes out the child processes started by vim only.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Well, having to "kill -9" processes to get back to Vim does not look like intended behavior.
I think we can use the old behavior, before patch 8.2.3941, when inside system().
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dorian Bivolaru
@brammool In his example kill -9 also doesn't work because sleep is finished already (defunct) but bash stays suspended so process cleanup does not happen. As bash is run in non-interactive mode, the child is in the same process group. This does not happen with bash -i -c (sleep 10) where the CTRL+Z only stops the child process.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> @brammool In his example `kill -9` also doesn't work because sleep is
> finished already (defunct) but bash stays suspended so process cleanup
> does not happen. As bash is run in non-interactive mode, the child is
> in the same process group. This does not happen with `bash -i -c
> (sleep 10)` where the CTRL+Z only stops the child process.
signal) and the shell doesn't.
When Vim is waiting for a system() command to finish, having CTRL-Z only
make that command pause makes no sense, since nothing can be done. The
only sensible thing to do is also make Vim sleep. Then when bringing it
to the foreground the system command continues until it's done.
I hope it can be made to work this way. I thought it worked before the
change, and the bisection confirms that.
--
hundred-and-one symptoms of being an internet addict:
130. You can't get out of your desk even if it's time to eat or time
to go to the bathroom.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Pavol Juhas
For some context, the blocked state occurs when some autocommand executes system call and user happens to press CTRL-Z at that moment. From users POV Vim does not suspend, is unresponsive, and there is no easy way of getting out of that state.
The SIGCONT using the command you mentioned, only affects the child sleep process and the bash invocation stays suspended. The sleep process becomes defunct after the 10 seconds are gone.
I see. I am using zsh which seems to do exec (process substitution) to run the sleep command. For bash the shell stays around so it needs to be signaled to continue as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
duplicate of #6565?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bryanf942
Patch v8.2.3941 is also causing nested vim to hang when ctrl-Z is pressed. As in,
vim foo # to enter a vim session
:!vim bar # to enter a nested vim session
ctrl-Z # stops the second vim, but the first vim does not also stop
Subsequent ctrl-Z and ctrl-C are ignored until 'kill -STOP $PID1' is done.
I reverted patch v8.2.3941 in master, and I no longer see this problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Chaim Halbert
I am still able to reproduce this problem on v8.2.4532 and v9.1.16, using :call system('sleep 10') followed by ctrl-z.
Neovim has solved this problem by waiting until the subprocess finishes before finally handling the ctrl-z. If after ctrl-z the user hits ctrl-c, the process is terminated immediately, and handling the ctrl-z is canceled.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Vitalio
Can this be fixed somehow? This is not just a sleep 10 problem it's only a reproducer. Real example, I run tig blame to view git blame blame on the current file and habitually press ^Z after this point terminal is unrecoverable hanged unless subprocess or vim itself is killed from in another screen.
Expected behavior is, when I suspend with ^Z inside of subcommand, vim should be suspended too (and I get into shell). Perhaps SIGSTOP should not be cached and left SIG_DFL? So when user press ^Z whole process group is suspended and not just subprocess (with a nested command) and vim remain up not knowing and not being able to do anything. Or at least make this behavior configurable?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.