mc hangs on start randomly with zsh when subshell is not disabled

[cederom]

Hello world :-)

I noticed recently that mc 4.8.26 on FreeBSD 12.2-RELEASE hangs on start sometimes with zsh. No rule when it happens. I need to kill -9 that process. When -b (no subshell) is provided then mc starts with no problem.

I found that common problem over the internets and -b as temporary workaround. I did not find that issue repoted here so here it goes :-)

Best regards :-)
Tomek

[andrew_b]

What reply do you expect? You just ignored all written in NewTicket page. I'm not FreeBSD used therefore bugreport like "4.8.26 on FreeBSD 12.2-RELEASE hangs on start" is useless for me.

-b is "no color". "No subshell" is -u. What do you mean exactly?

[cederom]

Take a look at:

​https://duckduckgo.com/?t=ffsb&q=midnight+commander+hangs+on+start&atb=v258-4__&ia=web

Looks like a common problem.

My mistake, its -u, thanks :-)

[zaytsev]

What's your shell? Does this happen on 4.8.25 or not?

We've had reports that persistent subshell buffer introduced in 4.8.26 somehow causes random hangs on zsh, but I think most FreeBSD people use tcsh and I think that our persistent subshell buffer implementation simply doesn't work on tcsh...

I wonder what should now happen on tcsh with the new patch, old behaviour or no subshell?

[cederom]

Thanks for you reply zaytsev :-)

Unfortunately I am using ZSH (version 5.8).

I found previous version mc 4.8.24 in my packages cache I will use that one for a while and let you know just to confirm.. that hanging on start showed up recently I am not sure when exactly :-)

What I can see is only a single blue background character in the top right corner of the terminal when the mc hangs. If you can hint me how can I search/debug further please let me know so I can provide more information :-)

[zaytsev]

Alright, so this should be the same problem as reported by Joseph Reagle on macOS :-/

It would be great if you could find a reproducer and even better check the code that has changed here: #4114 and see what could be the problem and suggest a fix - we don't use ZSH and with bash all seems to work fine.

Maybe it's a bad interaction with some plugin or prompt settings that you are using?

[cederom]

So far did not happen with 4.8.24. Will observe more. I am constantly working on ZSH so small probability of configuration problem if 4.8.24 works fine..?

Just to make sure that is ZSH problem when I get back to 4.8.26 I will use CSH and see what happens.

[zaytsev]

Again: we introduced a new feature in 4.8.26 - see #4114 - apparently it now causes sporadic hangs on ZSH. It would be great it ZSH users could debug and fix it.

[congest]

If you could just find a way to reliably reproduce it, I could fix it.

If you can't reliably reproduce the bug, the only think I can think of is to make sure mc is compiled with debugging symbols, and then wait for it to hang, and when it does, use gdb to attach to the process and figure out where it stopped.

[zaytsev]

Ticket #4214 has been marked as a duplicate of this ticket.

[meowmc]

Steps to reproduce:

1. brew install starship
2. open mc
3. ctrl-o
4. eval "$(starship init zsh)"
5. ctrl-o
6. go inside and out of a directory until it hangs on line src/subshell/common.c:781:

     if (select (maxfdp + 1, &read_set, NULL, NULL, wptr) == -1)
   

   See lldb-bt.txt.

GNU Midnight Commander 4.8.26-107-g8519c7e5b
starship 0.51.0
zsh 5.7.1 (x86_64-apple-darwin19.0)

mc 4.8.25 is okay.

[congest]

I'm sorry it took me a while to figure this out. I couldn't reproduce the bug, but eventually I did find a way to intentionally make mc freeze, just to test my bugfix.

I attached a patch.

The bug happens because mc tells the shell to perform a "cd" command, and waits indefinitely for the command to complete. If the shell, for some reason, cannot complete the "cd" command, mc just freezes indefinitely.

This patch removes all instances of mc waiting indefinitely for cd commands. Now, if the shell freezes while doing a "cd", mc will timeout after 1 second, and just set the subshell state to ACTIVE. If the user tries to run a command, they will get the error "The shell is already running a command".

I also simplified some other stuff where mc waits on the shell if an error occurred.

In feed_subshell(), I changed the timeout time from 10 seconds to 1 second. Ten seconds seemed like far too long to wait. Please let me know if this is an acceptable change. The rest of the bugfix will still work if the timeout is 1 second or 10 seconds.

If you want to reproduce the original bug, you can do this:

run mc
ctrl-o
Type: alias cd="sleep 30;echo"
ctrl-o
Try to change directories. mc will freeze for 30 seconds.

I still don't know _why_ the subshell just freezes sometimes. In any case, it's still a bad idea for mc to wait indefinitely for the subshell.

[aurrak]

Thanks @congest!

I tried out your patch and it did exactly as you described. MC no longer hangs/freezes (good), but once it gets to that state and you try to run a command in the shell, it shows the error "The shell is already running a command".

I suppose that's better than freezing.

[aurrak]

Not sure if it's related, but I tried disabling "oh-my-zsh" integration in my ~/.zshrc, and the issue doesn't happen anymore (cd doesn't hang) even without congest's patch.

I could be wrong, but I suspect something within ~/.oh-my-zsh/oh-my-zsh.sh (theme/plugin/git-status) is causing some conflicts.

[andrew_b]

Branch: 4198_hang_on_start_with_zsh
changeset:e89713a3d6a2edd4813958608ce461540c4f715e

[andrew_b]

Merged to master: [0c04e23821fe9b9d29f0075b171726067a32bdf8].

[reagle]

warning

[reagle]

no exit

[reagle]

4.8.27 kind of "fixed" 4.8.26 for those of us running zshell by removing the wait for commands to time out.

Occasionally I would not be able to execute a command: "Error: The shell is already running a command." And exiting mc in this state also throws: "Warning. The shell is still active. Quit anyway?"

Now, this problem happens frequently. I know I'm in trouble because when starting mc because the prompt line (second from the bottom, above the Function keys) shows a "^{[" at its start.}

The only way I've found to restore command functionality is to quit iterm2 itself (not just a given tab), but then the problem soon recurs.

@aurrak, were you able to figure anything else out?

[zaytsev]

Hi Joseph,

It would be helpful to understand why zsh hangs in the first place... The latest theory was that it is related to Oh My Zsh. Do you use it, or do you run plain zsh without any customisations? If you do use it, then which plugins do you use? Does disabling git plugin help?

--Yury

[reagle]

Yes, I run oh-my-zsh with the git plugin. Next time I have a moment for experimentation I'll install the latest mc, see if I can prompt the problem and then disable the git plugin and see if it goes away.

[activescott]

I'm on macOS+bash and in recent version(s) when switching to subshell just freezes until I press any button and returns to mc. Is this the same issue?

Installed via homebrew. My detailed versions are below...

$ 
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin20)

$ mc -V
GNU Midnight Commander 4.8.27
Built with GLib 2.68.3
Built with S-Lang 2.3.2 with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

$ sw_vers
ProductName:	macOS
ProductVersion:	11.6
BuildVersion:	20G165

$ uname -av
Darwin imac-ethernet.activenet 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

[reagle]

I disabled the git plugin in .zshrc, but still occasionally get "The shell is already running a command" error.

╰─➤ echo $plugins
osx zsh-autosuggestions

[reagle]

Closing my iterm does not solve the problem, so I'm reverting back to 4.8.25 .

[reagle]

Please re-open, this is not fixed.

[zaytsev]

How about the patch from #3121, does it help? If yes, then we should rather re-close this as a duplicate to have one open ticket per problem.

[flocsy]

mc 4.8.29 in MacOS 13.1 arch64 (homebrew). Still happens. Not related to execution of commands, even only changing directories in the panels (only using up/down/enter), after about 10 directory changes it freezes for ~30 seconds.
I also use Oh My Zsh and the git plugin. After I removed the git plugin (with only macos plugin) it still happens :(
Only after removing Oh My Zsh it seems to work fine. My guess is that it might be caused by the PROMPT.
I also noticed that when I don't have OMZ then I do see the prompt line in MC, but when I enable OMC then I don't see it.

[flocsy]

For others with this problem, this might be a workaround: ​https://github.com/ohmyzsh/ohmyzsh/issues/7383

[zaytsev]

I wonder if #3121 will solve most of the problems...

[qiolol]

Replying to congest:

I still don't know _why_ the subshell just freezes sometimes. In any case, it's still a bad idea for mc to wait indefinitely for the subshell.

I seem to've discovered at least one reason for the freezes: executing commands in your prompt.

I had some ​silly stuff set up that made use of PROMPT_COMMAND. As soon as I set that up, mc began to freeze when navigating directories and issue the "The shell is already running a command" dialog, along with a "The shell is still active. Quit anyway?" nag when attempting to quit. When I comment out PROMPT_COMMAND in my ~/.bashrc, mc behaves normally again.