Segfault in claude before its first answer in Fontconfig.discover

Discussed in #10420

^{Originally posted by krk January 23, 2026}

Issue Description

Ghostty crashes just before claude can print its first answer. This only started happening recently.

Expected Behavior

Not crashing.

Actual Behavior

Crashes.

Reproduction Steps

Start ghostty on Ubuntu 24 x86_64
Change to a project folder and start claude
Ask claude to "analyze project".
ghostty will segfault.

Also reproducible with ghostty-1.1.4-main+0d55a1d.

This only started happening recently.

Ghostty Logs

debug(app): mailbox message=redraw_surface
debug(font_codepoint_resolver): searching for a fallback font for cp=23BF

Thread 4 "renderer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7b157a5076c0 (LWP 763806)]
0x0000000004b013fd in FcCompare (pat=0x7b1564001ea0, fnt=0x7b15e3b75078, value=0x7b156405a098, result=0x7b157a501470, data=0x7b157a501310) at /x/.cache/zig/p/N-V-__8AAIrfdwARSa-zMmxWwFuwpXf1T3asIN7s5jqi9c1v/src/fcmatch.c:622
622	    while (i1 < pat->num && i2 < fnt->num)
(gdb) bt
#0  0x0000000004b013fd in FcCompare (pat=0x7b1564001ea0, fnt=0x7b15e3b75078, value=0x7b156405a098, result=0x7b157a501470, data=0x7b157a501310)
    at /x/.cache/zig/p/N-V-__8AAIrfdwARSa-zMmxWwFuwpXf1T3asIN7s5jqi9c1v/src/fcmatch.c:622
#1  0x0000000004b00cd7 in FcFontSetSort (config=0x3859b8c0, sets=0x7b157a501390, nsets=1, p=0x7b1564001ea0, trim=0, csp=0x0, result=0x7b157a501470)
    at /x/.cache/zig/p/N-V-__8AAIrfdwARSa-zMmxWwFuwpXf1T3asIN7s5jqi9c1v/src/fcmatch.c:1273
#2  0x0000000004b01e48 in FcFontSort (config=0x3859b8c0, p=0x7b1564001ea0, trim=0, csp=0x0, result=0x7b157a501470) at /x/.cache/zig/p/N-V-__8AAIrfdwARSa-zMmxWwFuwpXf1T3asIN7s5jqi9c1v/src/fcmatch.c:1399
#3  0x00000000033d6dc0 in config.Config.fontSort (self=0x3859b8c0, pat=0x7b1564001ea0, trim=false, charset=0x0) at /ws/tools/ghostty-1.1.4-main+0d55a1d/pkg/fontconfig/config.zig:27
#4  0x00000000033d667a in font.discovery.Fontconfig.discover (self=0x7b15e59e56a0, desc=...) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/font/discovery.zig:272
#5  0x00000000035e6996 in font.discovery.Fontconfig.discoverFallback (self=0x7b15e59e56a0, alloc=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7b15e3b75078
#6  0x000000000351dda4 in font.CodepointResolver.getIndex (self=0x7b15e59a10b0, alloc=..., cp=9151, style=regular, p=...)
    at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/font/CodepointResolver.zig:175
#7  0x00000000038f3d65 in font.SharedGrid.getIndex (self=0x7b15e59a1000, alloc=..., cp=9151, style=regular, p=...) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/font/SharedGrid.zig:166
#8  0x00000000038f42b3 in font.shaper.run.RunIterator.indexForCell (self=0x7b157a502ff0, alloc=..., cell=0x7b15abcafaa0, style=regular, presentation=...) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/font/shaper/run.zig:339
#9  0x00000000038f5e66 in font.shaper.run.RunIterator.next (self=0x7b157a502ff0, alloc=...) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/font/shaper/run.zig:221
#10 0x0000000003927eb2 in renderer.generic.Renderer(renderer.OpenGL).rebuildCells (self=0x7b15e0046000, wants_rebuild=false, screen=0x7b157a503778, screen_type=primary, mouse=..., preedit=..., cursor_style_=..., color_palette=0x7b157a5039c4)
    at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/generic.zig:2477
#11 0x000000000392d3cc in renderer.generic.Renderer(renderer.OpenGL).updateFrame (self=0x7b15e0046000, state=0x7b15e0052868, cursor_blink_visible=true) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/generic.zig:1263
#12 0x00000000038b3439 in renderer.Thread.renderCallback (self_=0x7b15e00528a8, r=0) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/Thread.zig:607
#13 0x00000000038b32b0 in renderer.Thread.wakeupCallback (self_=0x7b15e00528a8, r=0) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/Thread.zig:524
#14 0x000000000392e8ca in watcher.async.AsyncDynamic(dynamic.Xev(&.{ .io_uring, .epoll }[0..2])).wait__anon_545685__struct_573522.callback ()
    at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/watcher/async.zig:615
#15 watcher.async.AsyncEventFd(main.Xev(.io_uring,backend.io_uring)).wait__anon_573538__struct_593700.callback (ud=0x7b15e00528a8, l_inner=0x7b15e00528b8, c_inner=0x7b15e00529f8, r=...)
    at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/watcher/async.zig:117
#16 0x000000000387165f in backend.io_uring.Completion.invoke (self=0x7b15e00529f8, loop=0x7b15e00528b8, res=8) at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/backend/io_uring.zig:800
#17 0x00000000038742e9 in backend.io_uring.Loop.tick___anon_545893 (self=0x7b15e00528b8) at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/backend/io_uring.zig:189
#18 0x00000000038743de in backend.io_uring.Loop.run (self=0x7b15e00528b8, mode=until_done) at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/backend/io_uring.zig:80
#19 0x0000000003878f04 in dynamic.Xev(&.{ .io_uring, .epoll }[0..2]).Loop.run (self=0x7b15e00528b8, mode=until_done) at /x/.cache/zig/p/libxev-0.0.0-86vtc5b1EgB7vFmt9Tk7ySteR5AeEHW7xcR6gK9dMUD3/src/dynamic.zig:172
#20 0x0000000003879207 in renderer.Thread.threadMain_ (self=0x7b15e00528a8) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/Thread.zig:263
#21 0x000000000380e8c1 in renderer.Thread.threadMain (self=0x7b15e00528a8) at /ws/tools/ghostty-1.1.4-main+0d55a1d/src/renderer/Thread.zig:202
#22 0x000000000378c2bb in Thread.callFn__anon_517638 (args=...) at /x/.local/share/mise/installs/zig/0.14.1/lib/std/Thread.zig:488
#23 0x0000000003707f45 in Thread.PosixThreadImpl.spawn__anon_347233.Instance.entryFn (raw_arg=0x395786e0) at /x/.local/share/mise/installs/zig/0.14.1/lib/std/Thread.zig:757
#24 0x00007b15e809caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#25 0x00007b15e8129c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78



### Ghostty Version

```text
Ghostty 1.1.4-dev+0000000

Version
  - version: 1.1.4-dev+0000000
  - channel: tip
Build Config
  - Zig version: 0.14.1
  - build mode : builtin.OptimizeMode.Debug
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.generic.Renderer(renderer.OpenGL)
  - libxev     : io_uring
  - desktop env: other
  - GTK version:
    build      : 4.14.5
    runtime    : 4.14.5
  - libadwaita : enabled
    build      : 1.5.0
    runtime    : 1.5.0
  - libX11     : enabled
  - libwayland : enabled

OS Version Information

Ubuntu 24.04.3

(Linux only) Display Server

X11

(Linux only) Desktop Environment/Window Manager

GNOME 46

Minimal Ghostty Configuration

default

Additional Relevant Configuration

No response

I acknowledge that:

I have reviewed the FAQ and confirm that my issue is NOT among them.
I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

@abreufilho

Can reproduce locally by replaying either of the casts provided by @abreufilho:

Adding asciicast recordings as requested by @jcollie:

Crash (spinner triggers segfault):
https://asciinema.org/a/c97refzcxFW7bdrj

Working (same workflow, no crash):
https://asciinema.org/a/A8RFeyX4FctJBqmH

Edit: Working version using kitty.

I do not get the crash if I build with zig build -fsys=fontconfig so it appears to be a bug in the version of FontConfig that is bundled with Ghostty (2.14.2) that is fixed in newer versions (NixOS unstable provides 2.17.1).

I tried updating the internal copy of FontConfig to 2.17.1 (in #10435) but that does not fix the crash by itself.

@cyppe

@cyppe I hid your comment because it was not very useful. FontConfig doesn't even appear to have a --enable-thread-safe configure switch. And we enable the appropriate flags in our build already. I tried some of the other suggestions that the AI came up with and none of them worked.

I haven't looked at this specific crash but I will note that we did have some crashes before due to unsafe racing on fontconfig. I think Qwer added big locks around our font config stuff to prevent it... but maybe they didn't get to it? I can't remember the full context to any of it, but crashes in fontconfig due to unsafe multithreaded access is a thing we've seen before.

I did do an rr record/replay time-travel debugging session, which showed pango is munmap'ing the region ghostty is trying to read from. It is the region mapped to fontconfig cache with a path like: /x/.cache/fontconfig/0bd3dc0958fa2205aaaa8ebb13e2872b-le64.cache-8

Is this helpful?

With the help of claude code

I'm experiencing the same issue with a slightly different error manifestation.

Environment:

Ghostty: 1.2.3
OS: Ubuntu 25.10 (Wayland)
GNOME: 49
GTK: 4.18.5
Kernel: 6.17.0-12-generic

Log output:

Feb 01 12:08:31 ghostty[17165]: info(font_codepoint_resolver): found codepoint 0x23BF in fallback face=<error>
Feb 01 12:08:31 ghostty[17165]: free(): invalid size

Same codepoint (0x23BF), same trigger (Claude Code first response), but my crash manifests as heap corruption (free(): invalid size) rather than a segfault in FcCompare.

Workaround: Explicitly setting font-family prevents the crash by ensuring the glyph is found before hitting the buggy fallback path:

font-family = DejaVu Sans Mono
font-family = Noto Sans Mono CJK JP

The Noto Sans Mono CJK JP font contains 0x23BF, so the fallback resolution succeeds.

Same issue as i posted right here:
#10568

Started happening on the latest few ubuntu mesa versions,

Posted more comprehensive logs,

I do not get the crash if I build with zig build -fsys=fontconfig so it appears to be a bug in the version of FontConfig that is bundled with Ghostty (2.14.2) that is fixed in newer versions (NixOS unstable provides 2.17.1).

I haven't looked at this specific crash but I will note that we did have some crashes before due to unsafe racing on fontconfig. I think Qwer added big locks around our font config stuff to prevent it... but maybe they didn't get to it? I can't remember the full context to any of it, but crashes in fontconfig due to unsafe multithreaded access is a thing we've seen before.

-fsys=fontconfig does indeed fix it.
However bumping the fontconfig version did not,

Working build :
build with:
zig build -Doptimize=ReleaseSafe -fsys=fontconfig

Ghostty 1.3.0-main+e05a76b5c

Version
  - version: 1.3.0-main+e05a76b5c
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseSafe
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.18.9-x64v3-t2-questing-xanmod1
  - desktop env   : other
  - GTK version   :
    build         : 4.20.1
    runtime       : 4.20.1
  - libadwaita    : enabled
    build         : 1.8.0
    runtime       : 1.8.0
  - libX11        : enabled
  - libwayland    : enabled

Without fsys fontconfig:

Creating EGL context version 3.3 (debug:no, forward:no, legacy:no, es:no)          OpenGL version: 4.6 (core)
GLSL version: 4.60
Max texture size: 16384
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    base-instance: ✓
    buffer-storage: ✓
    external-objects: ✓
    external-objects-win32: ✗
Mesa: error: GL_INVALID_VALUE in glDeleteSync (not a valid sync object)            info(font_codepoint_resolver): found codepoint 0x2722 in fallback face=DejaVu Sans Mono                                                                               info(page_list): adjusting page capacity=.{ .cols = 83, .rows = 556, .styles = 128, .hyperlink_bytes = 384, .grapheme_bytes = 8192, .string_bytes = 2048 }
info(page_list): adjusting page capacity=.{ .cols = 83, .rows = 556, .styles = 128, .hyperlink_bytes = 768, .grapheme_bytes = 8192, .string_bytes = 2048 }
info(font_codepoint_resolver): found codepoint 0x23BF in fallback face=Noto Sans Mono CJK JP
fish: Job 1, 'GTK_DEBUG=interactive \
                              L…
                              M…' terminated by signal SIGSEGV (Address boundary error)

With it:

Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    base-instance: ✓
    buffer-storage: ✓
    external-objects: ✓
    external-objects-win32: ✗
Mesa: error: GL_INVALID_VALUE in glDeleteSync (not a valid sync object)
info(font_codepoint_resolver): found codepoint 0x2315 in fallback face=DejaVu Sans Mono
info(page_list): adjusting page capacity=.{ .cols = 83, .rows = 556, .styles = 128, .hyperlink_bytes = 384, .grapheme_bytes = 8192, .string_bytes = 2048 }
info(font_codepoint_resolver): found codepoint 0x23BF in fallback face=Noto Sans Mono CJK JP
info(page_list): adjusting page capacity=.{ .cols = 83, .rows = 556, .styles = 128, .hyperlink_bytes = 768, .grapheme_bytes = 8192, .string_bytes = 2048 }
info(font_codepoint_resolver): found codepoint 0x23F5 in fallback face=FreeMono

My 2c is that you really only need to add this to the source build documentation page. I get dozens of hits a day on my personal site from Claude/Codex users trying to solve this issue, and I think a simple warning/gotcha box on https://ghostty.org/docs/install/build would solve the urgent pain point

build: link to the system FontConfig by default on non-macOS systems

build: link to the system FontConfig by default on non-macOS systems (#…

Sync with upstream ghostty-org/ghostty (7 cmux patches on latest)

build: link to the system FontConfig by default on non-macOS systems

Merge upstream-main into main (#34)

Still reproducing on 1.3.1 (Ubuntu 24.04, NVIDIA RTX 6000 / X11)

Hit the same FcCompare crash as the original report. The fix in #11152 was reverted, so 1.3.1 still ships with the bundled fontconfig 2.14.2 (cache format version 8) while the system here runs fontconfig 2.15.0 (cache format 11). When Ghostty's bundled fc reads a stale ~/.cache/fontconfig/*.cache-8 written before some font was added/updated, it gets back patterns with dangling offsets and crashes in FcCompare.

Trigger: Claude Code's spinner glyph (cp 2722, ✳) needs font fallback. Crash is 100% deterministic — happens within seconds of Claude Code starting.

Stack trace (Debug build, ghostty-1.3.1 source):

fcmatch.c:622  FcCompare    while (i1 < pat->num && i2 < fnt->num)   ← SIGSEGV
fcmatch.c:1273 FcFontSetSort
fcmatch.c:1399 FcFontSort
pkg/fontconfig/config.zig:27   fontSort
src/font/discovery.zig:271     discover
src/font/CodepointResolver.zig:175  getIndex
src/font/SharedGrid.zig:180    getIndex
src/font/shaper/run.zig:340    indexForCell
src/renderer/generic.zig:2674  rebuildRow
src/renderer/Thread.zig:610    renderCallback

Workaround: mv ~/.cache/fontconfig ~/.cache/fontconfig.bak — Ghostty's bundled fc regenerates clean cache-8 files. Crash gone. (Will presumably recur whenever the system fontconfig next writes cache-11 files into the shared dir and something invalidates the cache-8 view.)

System: Ghostty 1.3.1 (self-built from source tarball, Zig 0.15.2), GTK 4.14.5, libadwaita 1.5.0, fontconfig 2.15.0, NVIDIA driver 580.126.09 — though as the maintainer comment on #11152 implies, GPU/driver is incidental; the bug is fontconfig global-state sharing.

Correction to my previous comment — proximate cause is two fontconfig copies in one process, not a cache version mismatch.

The crash recurred on the same machine after the cache wipe, with the cache directory now 100% clean (30 files, all cache-8, all written by Ghostty's bundled fc-2.14.2 — no cache-11 files have re-accumulated, system fc hasn't touched the dir since). So the
version-mismatch framing was misleading.

The real issue is what the maintainer comment on the (reverted) #11152 already said: Ghostty statically links its own fontconfig 2.14.2 while GTK4 dynamically links the system libfontconfig.so.1 (2.15.0). Two fontconfig instances now share the same address
space, the same on-disk caches, and (worse) the same FcConfig global singleton API surface — but they have independent in-process state (locks, pattern allocators, charset offsets). They race or read each other's freshly-rewritten mmap pages, and one of them
gets back an FcPattern* with dangling offsets. Hence FcCompare SIGSEGV.

The cache wipe "fixed" it temporarily only because it made both fontconfig copies start from identical fresh data — a coincidence, not a fix. Once GTK's fc-2.15.0 does any rescan or rewrite in the background, the race window reopens.

This means:

The bug is not user-fixable through config or cache management; it's a build-linkage issue.
-fsys=fontconfig (which build: link to the system FontConfig by default on non-macOS systems #11152 was going to make default on non-macOS) is the actual fix. I've rebuilt with that flag locally and the crash is gone.
Anyone building from source on a distro with fc ≥ 2.15.0 (Ubuntu 24.04+, Fedora 40+, Arch, etc.) will eventually hit this, with the trigger being any glyph that needs font fallback.

Suggestion: re-land #11152 (or whatever the reasoning was for the revert, surface it so the community can help unblock). The current default of bundling fontconfig is unsafe in the same process as GTK4.

Still reproduces on 1.3.2-main-+7092b3944 (GTK/OpenGL, Ubuntu 26.04 Wayland, GNOME 50.1, bundled fontconfig=21402), via Claude Code's spinner/tree UI (U+23BF, U+23F5). I captured a core dump and think I found the underlying mechanism, which also explains why the earlier fixes behaved the way they did.

Root cause: the executable exports its bundled fontconfig symbols, which interpose the system libfontconfig that GTK/Pango loads.

$ readelf --dyn-syms ./ghostty | grep -E ' Fc[A-Z]' | grep GLOBAL | grep -v UND | wc -l
27     # bundled fontconfig (2.14.2) Fc* symbols EXPORTED by the executable
       # FcPatternCreate, FcConfigGetCurrent, FcConfigSubstitute, FcFontSort, ...

Ghostty statically links bundled fontconfig 2.14.2 and exports these symbols. GTK/Pango/Cairo independently load the system libfontconfig.so.1 (2.17.1) into the same process (info sharedlibrary confirms it's mapped via libpangocairo/libpangoft2/libcairo). Because the executable's globals sit first in the link scope, they interpose the system library — so the two fontconfig instances end up sharing global/cache state. That's exactly the rr observation in this thread that "pango is munmap-ing the region ghostty is trying to read from" (~/.cache/fontconfig/...cache-8): Ghostty's fontconfig keeps reading a cache mapping that the system fontconfig (driven by pango) has torn down.

Crash backtrace (built -Dstrip=false), faulting on the renderer thread inside the bundled 2.14.2 fontconfig:

#0 FcCompare (fnt=<invalid>)   fcmatch.c:622   ; cmp (%rsi),%r12d, rsi=garbage
#1 FcFontSetSort               fcmatch.c:1273
#2 FcFontSort                  fcmatch.c:1399
#3 config.Config.fontSort      pkg/fontconfig/config.zig:27
#4 Fontconfig.discover         src/font/discovery.zig:277
#5 Fontconfig.discoverFallback src/font/discovery.zig:298
#6 CodepointResolver.getIndex (cp=U+23BF)  src/font/CodepointResolver.zig:175
#7 SharedGrid.getIndex → RunIterator.next → Renderer.rebuildRow/updateFrame → renderer.Thread

This explains the earlier results:

Bumping bundled fontconfig to 2.17.1 (pkg: update fontconfig to 2.17.1 #10435) didn't fix it — the two instances are still merged by interposition (and Ghostty installed via Nix crashed on freshly installed Kubuntu #12789 crashes with bundled fontconfig=21701 too).
-fsys=fontconfig does fix it — only one fontconfig in the process, nothing to interpose.

A fix that keeps fontconfig bundled: hide the bundled symbols so they can't interpose the system lib. In pkg/fontconfig/build.zig, add to the C flags:

"-fvisibility=hidden",

After this, readelf --dyn-syms shows 0 exported Fc* (still statically linked, just not exported), the two fontconfigs are fully isolated, and the crash no longer reproduces — verified with a default (bundled) ReleaseFast build.

(Heads-up for a follow-up: the bundled freetype (57 exported FT_*) and harfbuzz (518 exported hb_*) are the same latent interposition hazard against the system libs GTK loads, but they need different handling — -fvisibility=hidden doesn't hide FT_* because FreeType forces visibility("default") via FT_EXPORT.)

A fix that keeps fontconfig bundled: hide the bundled symbols so they can't interpose the system lib. In pkg/fontconfig/build.zig, add to the C flags:

"-fvisibility=hidden",

This is not a good solution. On systems that are linking to GTK, fontconfig should be dynamically linked to the system fontconfig. There's no reason not to as the rest of GTK is dynamically linked. The only reason that we have an option to statically link the bundled fontconfig is for platforms like macOS where fontconfig is not used by the system. There are probably much more subtle problems (the least of which would be increased memory usage) when statically linking a copy of fontconfig when GTK dynamically links to the system copy.

This is not a good solution. On systems that are linking to GTK, fontconfig should be dynamically linked to the system fontconfig. There's no reason not to as the rest of GTK is dynamically linked. The only reason that we have an option to statically link the bundled fontconfig is for platforms like macOS where fontconfig is not used by the system. There are probably much more subtle problems (the least of which would be increased memory usage) when statically linking a copy of fontconfig when GTK dynamically links to the system copy.

Gotcha. In that case, I confirmed that -fsys=fontconfig also fixes the issue.

This is happening for me on a build as recent as 07d3166.
I built with debug, and ghostty crashed on python -c 'for i in range(30,128):print(chr(i)), which corrobates the "missing glyph" thing.

I thought that since #11152 effectively does -fsys=fontconfig (IIRC) this should not happen, right?

output of crash attached. ghosttty +crash-report does not list anything, tho.

crash.txt

build: hide bundled fontconfig symbols to prevent interposition

[ghostty] pin box-drawing and braille glyphs to Symbols Nerd Font Mono

Navigation Menu

Repository navigation

Segfault in claude before its first answer in Fontconfig.discover #10432

Discussed in #10420

Issue Description

Expected Behavior

Actual Behavior

Reproduction Steps

Ghostty Logs

OS Version Information

(Linux only) Display Server

(Linux only) Desktop Environment/Window Manager

Minimal Ghostty Configuration

Additional Relevant Configuration

I acknowledge that:

Without fsys fontconfig:

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segfault in claude before its first answer in Fontconfig.discover #10432

Description

Discussed in #10420

Issue Description

Expected Behavior

Actual Behavior

Reproduction Steps

Ghostty Logs

OS Version Information

(Linux only) Display Server

(Linux only) Desktop Environment/Window Manager

Minimal Ghostty Configuration

Additional Relevant Configuration

I acknowledge that:

Activity

jcollie commented on Jan 24, 2026

jcollie commented on Jan 24, 2026

jcollie commented on Jan 24, 2026

cyppe commented on Jan 26, 2026

jcollie commented on Jan 26, 2026

mitchellh commented on Jan 26, 2026

krk commented on Jan 27, 2026

peterzandbergen commented on Feb 1, 2026

hlpmenu commented on Feb 4, 2026

hlpmenu commented on Feb 9, 2026

Without fsys fontconfig:

16 remaining items

mjbommar commented on Mar 3, 2026

haoquanl commented on May 13, 2026

asmello commented on Jun 7, 2026

jcollie commented on Jun 7, 2026

asmello commented on Jun 7, 2026

krono commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions