Unable to start wezterm with brew installed JetBrains Mono font present

[ssoriche]

Describe the bug

After changing the font configured in ~/.config/wezterm/wezterm.lua, Wezterm locked up (spinning beachball of death) and I had to force quit it. After which I have not been able to restart Wezterm.

Things I've tried:

• Uninstall and reinstall
• Use release version
• Use HEAD version
• Reboot
• Remove ~/.cache/local/wezterm
• Remove ~/.config/wezterm/wezterm.lua

I have tried starting using the WezTerm.app and from within Terminal.app to get a better idea of what is going on. In both cases the icon appears in the desktop and shortly after Wezterm shows as Not Responding.

Environment (please complete the following information):

• OS: macOS 10.15.7
• Version: wezterm 20210203-095643-70a364eb-26-g9bf419eb

To Reproduce

Steps to reproduce the behavior.

I don't know if someone else can reproduce this. Changing the font on my other systems has had the same lockup/beachball effect if I didn't have the font installed, but wezterm has never failed to start afterwards.

Configuration

Default configuration when there is no configuration.

Expected behavior

New terminal opens.

Screenshots

If applicable, add screenshots to help explain your problem. Screenshots are most
appropriate for rendering issues.

Session Recording

I tried to run wt-record but because wezterm doesn't start, it never gets to run the script to do the recording or dump the output.

Additional context

I'm attaching the results from the Console filtered on wezterm and the output from env WEZTERM_LOG=trace RUST_BACKTRACE=1 wezterm, hopefully these can provide some insight.

wezterm_trace.txt

wezterm_console_logs.txt

It seems to me that there is a state recorded somewhere and that wezterm is trying to get back to that, but this is outside of my knowledge of how to fix.

[wez]

That's weird! It seems stuck fairly early on in setting up some background machinery that isn't directly part of wezterm.

Can you try starting wezterm again and then use the Activity Monitor to "sample" the wezterm process? (highlight the wezterm process, then use the gear icon to pop up a menu and select "sample process"). That might give some clues as to what is happening. Please share the sample with me!

To try to unblock, the only persistent state that wezterm directly, actively maintains is /Users/ssoriche/.local/share/wezterm/. You could try removing that and see if it helps.

If that doesn't work, macOS maintains its own state information in ~/Library/Preferences/com.github.wez.wezterm.plist. You could try removing that and see if it helps (please only remove one of these files at a time and re-test, so that we can tell which one made the difference!)

[ssoriche]

As requested here are the samples for both WezTerm.app and the wezterm-mux-server. Thought I'd give you both just in case. I will proceed to try your other suggestions now.

Sample of wezterm-mux-server.txt
Sample of WezTerm.txt

[ssoriche]

Deleting the directory nor the plist file had any effect. Attaching a sample from after removing the .plist file in case it is of value.

Sample of WezTerm - new.txt

[wez]

The sample appears to be focused around font loading. Have you recently changed something with the fonts on your machine?

Two possible things feel plausible based on that sample:

• If you installed JetBrains Mono for yourself, maybe the ttf-parser doesn't like that version of that font?
• Something in your default shell startup outputs glyph(s) that aren't in the default font, and wezterm is falling back to trying to find a working fallback font from the system, but there are lots of fonts for it to work through and/or some of them it's having trouble parsing. You might try running wezterm start -- bash --norc to skip loading any rc or dotfiles and see if that resolves things (or whatever the equivalent is for your preferred fish shell!).

I'd expect to see some logging about either of those things happening, so I'm not 100% convinced that we've identified the issue so far.

[ssoriche]

I did use brew to recently install JetBrains Mono. I was using JetBrains Mono Nerd Font before (but it has an issue drawing proper TUI boxes!).

Wezterm start -- bash --norc landed me in the same position, however removing the JetBrains Mono font and restarting wezterm worked!

If you want to try it yourself, the font I installed was from here https://github.com/JetBrains/JetBrainsMono

[wez]

Hmm, I manually installed JetBrains Mono (brew doesn't work on M1 macs, or didn't when I set this up and I don't need it here), and I can't reproduce this issue. I'll see if I can reproduce it on my intel mac when that next convenient to test.

[ssoriche]

I tried reinstalling JetBrains Mono with brew to see if I could get the problem to trip again and it didn't work. It might have been a one time issue.

[wez]

I briefly tried to reproduce this yesterday by manually installing the fonts into fontbook but couldn't with master. I believe that it happened because a couple of people seem to have run into this and because of the sample output above.

[ssoriche]

I managed to cause another computer to go into a beachball and lock up wezterm. I installed JetBrainsMono again via brew as before. I immediately edited ~/.config/wezterm/wezterm.lua and sent my font via:

return {
    font = wezterm.font("JetBrainsMono"),
}

Once I saved the file wezterm changed to Not Responding, but that did not keep me from being able to Force Kill and restart wezterm.

I then edited the font setting again, this time changing JetBrainsMono to JetBrains Mono which again caused the beachball to appear, and a Force Quit was required. Interestingly, I can restart wezterm, but when I try to do things in the terminal, it locks up again after a few characters. I may have achieved the previous state.

When I start Font Book and select JetBrains Mono, it tells me:

 Multiple copies of this font are installed

And that I can resolve this Manually or Automatically.

I am not doing anything else to this environment so that if there is any poking about or details you need, I should be able to get them.

[ssoriche]

I had a quick look at the entries in Font Book, image attached. This seems like an issue with how brew is installing fonts. However I think wezterm could handle the situation better and not hang. I've left my computer in this state in case there's any more information I can provide, however I am finding Terminal.app severely lacking.

[wez]

While looking at another issue, I ran into an unterminated loop resolving fonts on my mac. I'm pretty sure that it was the cause of the problems you had here! The primary trigger was if macOS decorated the name with a suffix like "Roman" and we couldn't find a font with that name in the underlying file.

[ssoriche]

I tested this out on the last Mac I had left that I hadn't installed JetBrains Mono on, and it worked. Conditions on that Mac are the same as listed above and wezterm is running, so I think we can call this issues fixed.

Thank you again for the continued awesome support and product!

[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.