Ticket #4198 (closed defect: fixed)

Opened 7 months ago

Last modified 19 hours 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 :-)
Tomek

Attachments

lldb-bt.txt (2.6 KB) - added by meowmc 6 months ago.
cdfreeze.patch (5.0 KB) - added by congest 3 months ago.
Screen Shot 2021-09-18 at 08.02.52.png (40.9 KB) - added by reagle 41 hours ago.
warning
Screen Shot 2021-09-18 at 08.03.07.png (4.6 KB) - added by reagle 41 hours ago.
no exit

Change History

comment:1 Changed 7 months ago by andrew_b

  • Milestone 4.8.27 deleted

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

comment:4 Changed 7 months 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 7 months 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 7 months 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 7 months 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 7 months 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 7 months ago by cederom (previous) (diff)

comment:9 Changed 7 months 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 7 months 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 6 months ago by zaytsev

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

Changed 6 months ago by meowmc

comment:12 Changed 6 months 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 6 months ago by andrew_b

  • Milestone set to Future Releases

comment:14 Changed 5 months ago by z0rc

  • Cc z0rc3r@… added

comment:15 Changed 3 months ago by aurrak

  • Cc aurrak@… added

comment:16 Changed 3 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
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.

Changed 3 months ago by congest

comment:17 Changed 3 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 3 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 3 months ago by aurrak (previous) (diff)

comment:19 Changed 3 months ago by andrew_b

  • Status changed from new to accepted
  • Owner set to andrew_b
  • 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
changeset:e89713a3d6a2edd4813958608ce461540c4f715e

comment:20 Changed 2 months ago by andrew_b

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

comment:21 Changed 2 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 2 months ago by andrew_b

  • Status changed from testing to closed

Changed 41 hours ago by reagle

warning

Changed 41 hours ago by reagle

no exit

comment:23 Changed 41 hours 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.

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

Last edited 41 hours ago by reagle (previous) (diff)

comment:24 Changed 19 hours 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?

--Yury

Note: See TracTickets for help on using tickets.