5

I had vim open in a terminal; I needed to check some other things so I typed Ctrl-Z. When I later type fg, it just stopped again:

myprompt$ fg
vim newfile path/to/existingfile

[1]+  Stopped                 vim newfile path/to/existingfile

[1]+  Stopped                 vim newfile path/to/existingfile
myprompt$ 

Sometimes, as shown above, it even stops twice.

It looks like the shell is attempting to resume vim but that it just halts again.

I have quite a bit of work typed into newfile; how can I either resume successfully or kill the job and retain the work I did?

Wildcard
  • 4,409
  • 26
  • 49

2 Answers2

4

If you are seeing this when using zsh versions 5.7 through 5.8.1, it is due to a known bug that has been fixed by Erik Paulson in zsh 5.9:

https://www.zsh.org/mla/workers/2021/msg01255.html

What's happening is zsh "fg" is sometimes sending two SIGCONT signals to the stopped job. Normally only one SIGCONT should be sent, so that's the bug. For some unknown reason, vim interprets the second SIGCONT as a reason to stop itself, so the net effect is that zsh fg sometimes fails to restore a stopped vim.

As Paulson noted, this zsh fg bug can cause a stopped emacsclient to crash.

I have reported the bug to Ubuntu, since it affects zsh on Ubuntu 20.04 and 22.04 LTS: https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1987991

This post on Stack Overflow was quite helpful to me in tracking down this bug: https://stackoverflow.com/questions/64531411/why-do-i-receive-two-sigcont-signals

fjarlq
  • 141
  • 3
  • 1
    I don't see that behavior for zsh version 5.8.1 (with vim 9.0) or zsh 5.8.1 (with vim 8.2) on Fedora, nor do I see it for zsh 5.6 (with vim 8.2) on SUSE Enterprise. I also don't see it with zsh 5.1.1 (vim 7.2) for Ubuntu. Perhaps it's only a problem with an Ubuntu build? – karlh Aug 29 '22 at 01:20
  • Good question, I don't know. It can be difficult to reproduce this even on Ubuntu. Normally, SIGCONT does not cause vim to stop. There seems to be a short window of time after being restarted when a second SIGCONT causes vim to stop again. So it's something of a race condition whether the second SIGCONT hits that window or not. Also, perhaps more importantly, the zsh bug does not always happen... usually zsh does not send an extra SIGCONT with one fg. – fjarlq Aug 29 '22 at 06:44
3

Okay, I handled it via kill %1, then vim and then within vim, :recover newfile. Still don't know why it happened but I'm very happy there was a way to recover the file!

The swap file hung around and made vim complain next time I opened the file, so I just removed the swapfile after the file was recovered properly.

Wildcard
  • 4,409
  • 26
  • 49