Skip to content

SIGSEGV at startup on Fedora 44: bundled fontconfig + glycin SVG icon loader #12554

Closed as not planned

Description

@Jarbowsky

Summary

Ghostty 1.3.1 segfaults at startup on Fedora 44 every launch (terminal and app launcher). The crash is in gtk_window_realize_icon → glycin (gdk-pixbuf SVG loader) → fontconfig, and appears to be the same root cause as #10568 / #11152 (bundled fontconfig symbol interposition) but via a different trigger path: window icon loading rather than font rendering via libpangoft2.

PR #11152 ("link to system FontConfig by default on non-macOS systems") would have fixed this but was reverted, so 1.3.1 still ships the bundled fontconfig and the bug is reachable on a vanilla install.

Environment

  • Ghostty: 1.3.1-2.fc44 (Fedora package)
  • OS: Fedora 44, kernel 6.19.14-300.fc44.x86_64, Wayland session
  • GTK 4.22.3, libadwaita 1.9.0
  • glycin-libs 2.1.1-1.fc44 (glycin 3.1.0)
  • Mesa 26.0.5-3.fc44, Intel UHD 630
  • fontconfig: system version (Ghostty's bundled is loaded via symbol interposition)

Reproduction

  1. Install ghostty from Fedora 44 repos.
  2. Run ghostty from any terminal.
  3. → SIGSEGV (Address boundary error) before the window appears.

Stack trace (top frames)

#0  FcStrSetDestroy                              libfontconfig.so.1
#1  IA__FcConfigDestroy.part.0                   libfontconfig.so.1
#2  FcConfigGetCacheDirs                         libfontconfig.so.1
#3  std::sync::once::Once::call_once_force       libglycin-2.so.0
#4  std::sys::sync::once::futex::Once::call      libglycin-2.so.0
#6  glycin::sandbox::Sandbox::bwrap_command      libglycin-2.so.0
#7  glycin::sandbox::Sandbox::spawn              libglycin-2.so.0
#11 gly_loader_load                              libglycin-2.so.0
#12 load_pixbuf_with_glycin                      libgdk_pixbuf-2.0.so.0
#13 gdk_pixbuf__glycin_image_stop_load           libgdk_pixbuf-2.0.so.0
#16 gdk_pixbuf_new_from_stream                   libgdk_pixbuf-2.0.so.0
#17 gdk_texture_new_from_bytes                   libgtk-4.so.1
#23 icon_list_from_theme                         libgtk-4.so.1
#24 gtk_window_realize_icon                      libgtk-4.so.1
#25 gtk_window_realize                           libgtk-4.so.1
...
#39 apprt.gtk.class.application.Action.initAndShowWindow   /usr/bin/ghostty

Full coredump available via coredumpctl info.

Why this is the same root cause as #10568

glycin (linked against system libfontconfig) calls FcConfigGetCacheDirs while preparing the bwrap sandbox. Due to symbol interposition from Ghostty's exported bundled fontconfig symbols, the call resolves into Ghostty's bundled copy, whose internal state is incompatible with how glycin uses it — leading to the use-after-free / double-free style crash in FcStrSetDestroy.

This is not a glycin bug per se: glycin works correctly in every other GTK4 app on this system (Files, Image Viewer, etc.). Only Ghostty triggers it because only Ghostty exports its bundled fontconfig into the global symbol table.

Workaround

Disable Fontconfig in glycin's SVG loader config so glycin doesn't call into fontconfig during sandbox setup:

mkdir -p ~/.local/share/glycin-loaders/2+/conf.d
for f in /usr/share/glycin-loaders/2+/conf.d/*.conf; do
    sed 's/Fontconfig=true/Fontconfig=false/g' "$f" > ~/.local/share/glycin-loaders/2+/conf.d/$(basename "$f")
done
# launch with: GLYCIN_DATA_DIR=$HOME/.local/share/glycin-loaders ghostty

This bypasses the crash but is obviously not a real fix — it just avoids the codepath that surfaces the underlying symbol interposition bug.

Suggested fixes

  1. Re-land build: link to the system FontConfig by default on non-macOS systems #11152 (link to system fontconfig on Linux), or
  2. Add -fvisibility=hidden to the bundled fontconfig build flags so the bundled symbols don't leak into the global symbol table (mentioned in font rendering segv/panic rendering certain (pot. libgallium issue?) #10568 as a candidate).

Either approach should fix both this crash and the libpangoft2 crash in #10568.

Activity

  1. ghostty-vouch commented on May 2, 2026

    @ghostty-vouch
    Contributor

    Hi @Jarbowsky, thanks for your interest!

    Non-maintainers are not allowed to create issues in this repository — we ask that you create a discussion first. For more details on the why, see #3558 and our CONTRIBUTING.md.

    This issue will be closed automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions