alacritty: Crash on startup (macOS): 'A font must have a non-null family name.'

Alacritty crashes on macOS on startup. No custom alacritty.yml is defined.

System

OS: macOS BigSur 11.6.6 (20G624) Version: alacritty 0.10.1 (2844606)

Logs

Crashes:

$ alacritty 
thread 'main' panicked at 'A font must have a non-null family name.', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/core-text-19.2.0/src/font_descriptor.rs:223:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ RUST_BACKTRACE=1 alacritty 
thread 'main' panicked at 'A font must have a non-null family name.', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/core-text-19.2.0/src/font_descriptor.rs:223:19
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display
   3: core::option::expect_failed
   4: crossfont::darwin::Descriptor::new
   5: crossfont::darwin::Descriptor::to_font
   6: <crossfont::darwin::Rasterizer as crossfont::Rasterize>::load_font
   7: alacritty::renderer::GlyphCache::load_regular_font
   8: alacritty::display::Display::new
   9: alacritty::event::Processor::create_window
  10: alacritty::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 39 (17 by maintainers)

Commits related to this issue

Most upvoted comments

Looks like we could query kCTFontEnabledAttribute but core-text doesn’t provide an accessor to it. I hacked in an is_enabled method and an associated get_number_attribute and can confirm that if I filter the list at the end of cascade_list_for_languages with my is_enabled check, alacritty starts up just fine.

So, @chrisduerr, I leave it to you how to proceed – is this something you’d want bring into crossfont, or file an upstream bug with core-text?

OK I think I have some more information that might be relevant.

I did some tweaks to the core-text crate to investigate what was happening when it couldn’t get a family name. Specifically, I added a log here to print out the font name attribute if it couldn’t get the family name.

Right before the panic, what I got was CourierNewPSMT. That was indeed a font installed on my system, but it was disabled in Font Book.

Once I re-enabled it and ran again, the list got much further, but this time it panicked right after Kailasa which, you guessed it, was disabled.

So this might be an upstream bug in core-text where it’s not properly able to query fonts that are installed but disabled. I’ll investigate if there’s anything more clever crossfont can do to not pay attention to disabled fonts.

Compiled the main branch, can confirm it works for me. 🎉 Just wanted to say a big thank you to everyone involved hunting down and fixing this, you are awesome! 💪

I think the uprev of crossfont in #6186 may fix this?

yeah, go ahead. we can always help you clean it up if something is wrong.

@sjml Looks like you’re on to something. I have disabled fonts on my system as well (all the asian, cyrillic and hebrew fonts that ship with macOS, for example).

To be sure, I just uninstalled all non-system fonts from both ~/Library/Fonts and /Library/Fonts, leaving only the protected ones in /System/Library/Fonts, but am still having the panic, so I’m starting to think maybe it’s not a problem with the installed fonts… 😕

Happy take a look, but that’s in a dependent project, not the central alacritty one, so the source doesn’t come with this repository. Is there any dev-setup documentation to get it up and debuggable quickly? (Sorry, I know enough about Rust to write some code and do simple debugging, but haven’t done anything with debugging dependencies as of yet.)