Ticket #4198 (closed defect: fixed)

Opened 2 years ago

Last modified 6 weeks ago

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

Reported by: cederom Owned by: andrew_b
Priority: critical Milestone: 4.8.27
Component: mc-core Version: master
Keywords: subshell hang Cc: joseph.2011@…, congest, z0rc3r@…, aurrak@…
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description (last modified by zaytsev) (diff)

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 :-)


lldb-bt.txt (2.6 KB) - added by meowmc 2 years ago.
cdfreeze.patch (5.0 KB) - added by congest 21 months ago.
Screen Shot 2021-09-18 at 08.02.52.png (40.9 KB) - added by reagle 19 months ago.
Screen Shot 2021-09-18 at 08.03.07.png (4.6 KB) - added by reagle 19 months ago.
no exit

Change History

comment:1 Changed 2 years ago by andrew_b

  • Milestone 4.8.27 deleted

comment:2 Changed 2 years ago by 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?

comment:3 Changed 2 years ago by cederom

Take a look at:


Looks like a common problem.

My mistake, its -u, thanks :-)

comment:4 Changed 2 years ago by 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?

comment:5 Changed 2 years ago by 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 :-)

comment:6 Changed 2 years ago by zaytsev

  • Description modified (diff)
  • Summary changed from mc hangs on start randomly when subshell is not disabled to mc hangs on start randomly with zsh when subshell is not disabled

comment:7 Changed 2 years ago by zaytsev

  • Cc joseph.2011@… added

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?

comment:8 Changed 2 years ago by 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.

Last edited 2 years ago by cederom (previous) (diff)

comment:9 Changed 2 years ago by zaytsev

  • Cc congest added

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.

comment:10 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by zaytsev

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

Changed 2 years ago by meowmc

comment:12 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by andrew_b

  • Milestone set to Future Releases

comment:14 Changed 2 years ago by z0rc

  • Cc z0rc3r@… added

comment:15 Changed 21 months ago by aurrak

  • Cc aurrak@… added

comment:16 Changed 21 months ago by 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
Type: alias cd="sleep 30;echo"
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.

Changed 21 months ago by congest

comment:17 Changed 21 months ago by 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.

comment:18 Changed 21 months ago by 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.

Last edited 21 months ago by aurrak (previous) (diff)

comment:19 Changed 21 months ago by andrew_b

  • Owner set to andrew_b
  • Status changed from new to accepted
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.27

Branch: 4198_hang_on_start_with_zsh

comment:20 Changed 21 months ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:21 Changed 21 months ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

comment:22 Changed 21 months ago by andrew_b

  • Status changed from testing to closed

Changed 19 months ago by reagle


Changed 19 months ago by reagle

no exit

comment:23 Changed 19 months ago by 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.



Version 0, edited 19 months ago by reagle (next)

comment:24 Changed 19 months ago by 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?


comment:25 Changed 19 months ago by 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.

comment:26 Changed 18 months ago by 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

comment:27 Changed 17 months ago by 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

comment:28 Changed 17 months ago by reagle

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

comment:29 Changed 13 months ago by reagle

Please re-open, this is not fixed.

comment:30 Changed 13 months ago by 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.

comment:31 Changed 6 weeks ago by 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.

comment:32 Changed 6 weeks ago by flocsy

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

Note: See TracTickets for help on using tickets.