Freeze when closing pane on arm64 when running fish

[supermarin]

Describe the bug

WezTerm freezes (beachball) and has to be force quit upon closing tabs.

Environment (please complete the following information):

• OS: Macbook Air M1, Big Sur 11.2.2
• Version: WezTerm nightly, but issue occurs in the last release as well
• wezterm -V: wezterm 20210314-114017-04b7cedd-13-g3d0f3eae

To Reproduce

1. Open more than 1 tab
2. Close the pane (e.g. CMD+W)
3. Get prompted by WezTerm, press Y
4. Beachball

Configuration

$ cat ~/.config/wezterm/wezterm.lua
return {
  color_scheme = "Dracula+",
  font_size = 13.0,
  line_height = 1.20,
  window_padding = {
    left = 10,
    right = 10,
    top = 10,
    bottom = 10,
  },
};

Expected behavior

No freeze

[wez]

I can't reproduce this on my M1 macbook air.
Can you run:

WEZTERM_LOG=trace wezterm 2> /tmp/wezterm.txt

reproduce the issue and attach /tmp/wezterm.txt to this issue?

[supermarin]

// deleted gist

[supermarin]

OK here's an interesting fact: closing with EOF (pressing in the shell) works.
Closing with CMD+W displays the yes/no prompt and then freezes.

[wez]

The trace doesn't show what may be stuck. Another thing to try is: reproduce the hang, then in Activity Monitor, select WezTerm, use the ... menu to Sample Process and also to Spindump and get both of those pieces of info over to me

[supermarin]

// deleted gist

[wez]

OK! This:

  Thread 0x6c62af    DispatchQueue "com.apple.main-thread"(1)    1001 samples (1-1001)    priority 46 (base 46)
  1001  _$LT$window..os..macos..connection..Connection$u20$as$u20$window..connection..ConnectionOps$GT$::run_message_loop::hf96cd61fa407bbef + 24 (wezterm-gui + 11731952) [0x10132c3f0]
    1001  -[NSApplication run] + 600 (AppKit + 204896) [0x18f8f5060]
      1001  -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1312 (AppKit + 262572) [0x18f9031ac]
        1001  _DPSNextEvent + 868 (AppKit + 268332) [0x18f90482c]
          1001  _BlockUntilNextEventMatchingListInModeWithFilter + 76 (HIToolbox + 200996) [0x194c4f124]
            1001  ReceiveNextEventCommon + 320 (HIToolbox + 201348) [0x194c4f284]
              1001  RunCurrentEventLoopInMode + 292 (HIToolbox + 202180) [0x194c4f5c4]
                1001  CFRunLoopRunSpecific + 600 (CoreFoundation + 530240) [0x18d12a740]
                  1001  __CFRunLoopRun + 768 (CoreFoundation + 532908) [0x18d12b1ac]
                    1001  __CFRunLoopDoObservers + 576 (CoreFoundation + 535636) [0x18d12bc54]
                      1001  std::process::Child::wait::ha72eb9db8265edcf + 88 (wezterm-gui + 12470420) [0x1013e0894]
                        1001  __wait4 + 8 (libsystem_kernel.dylib + 31824) [0x18cfffc50]
                         *1001  ??? (kernel.release.t8101 + 5593228) [0xfffffe000815588c] (blocked by wait4 on UNKNOWN [76574])

is probably this one: https://github.com/wez/wezterm/blob/main/mux/src/localpane.rs#L569

Since I haven't seen this happen with zsh or bash, and you're using fish, I'm going to assume that there is something about fish's config that puts things in a state where the wait call never returns.

Would you mind reproducing this again, and capturing the process tree under the wezterm process? If you have pstree you can run something like pstree -p $(pgrep wezterm-gui) to capture it. Otherwise, I can manually figure it out from the ps -axf output if you don't mind sharing that.

[supermarin]

$ pstree -p 78620                                                                                          Users/supermarin-+= 00001 root /sbin/launchd
 \-+= 78620 supermarin /Applications/WezTerm.app/Contents/MacOS/wezterm-gui
   |-+= 78626 supermarin /usr/local/bin/fish -l
   | \-+= 78776 supermarin pstree -p 78620
   |   \--- 78777 root ps -axwwo user,pid,ppid,pgid,command
   \--= 78722 supermarin /usr/local/bin/fish -l

hm, now much interesting info in there.

Fish:

$ fish --version
fish, version 3.2.1
$ lipo -info $SHELL
Architectures in the fat file: /usr/local/bin/fish are: x86_64 arm64

[wez]

I've pushed a commit that should avoid blocking forever in this case, assuming that I identified the right place.
That'll show up in the nightly downloads within an hour and I'd appreciate it if you could try it and report back!

[supermarin]

@wez sorry wasn't online yesterday evening, confirming the fix! Thank you so much for the fast fix

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.