Segfault in claude before its first answer in Fontconfig.discover

[jcollie]

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

1. Start ghostty on Ubuntu 24 x86_64
2. Change to a project folder and start claude
3. Ask claude to "analyze project".
4. 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.

[jcollie]

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.

[jcollie]

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

[jcollie]

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

[cyppe]

Also have experienced increase in crashes last 1-2 weeks. Asked claude to do investigation in case there is anything useful.

If this is just slop - ignore it. But posting in case something interesting/useful was catched. And if it crashes again I will update.

---

Note: This is an ongoing investigation. I've applied the -fsys=fontconfig workaround and am monitoring for crashes. Will update this comment with results. If it crashes again, I'll gather fresh diagnostics and report back.

---

I'm experiencing what appears to be the same or a closely related issue. Adding my crash data and test results.

My Environment

Component	Details
OS	Arch Linux (rolling)
Kernel	6.18.6-arch1-1
Display Server	Wayland
GPU	AMD Strix Halo (Radeon Graphics) - integrated APU
Mesa	25.3.4-1
System Fontconfig	2.17.0 (via pacman)
Ghostty Version	tip builds from source
Font	JetBrainsMono Nerd Font

Crash Frequency (Before Workaround)

9 crashes in 10 days - multiple crashes per day, all in the renderer thread with SIGSEGV.

System Logs (Example Crash)

Jan 26 14:28:51 beefy kernel: renderer[4107498]: segfault at 7f3aab006e65 ip 000000000285882b sp 00007f3cc17dc4b0 error 4 in ghostty[185782b,22ab000+b46000] likely on CPU 28 (core 12, socket 0)
Jan 26 14:28:51 beefy systemd-coredump[582114]: Process 4104530 (ghostty) of user 1000 terminated abnormally with signal 11/SEGV, processing...

Coredump Info

           PID: 4104530 (ghostty)
        Signal: 11 (SEGV)
     Timestamp: Mon 2026-01-26 14:28:51 CET
  Command Line: /home/cyppe/.local/bin/ghostty --gtk-single-instance=true --working-directory=/home/cyppe
    Executable: /home/cyppe/.local/share/ghostty/versions/20260122-4acd33954/ghostty

Stack trace of thread 4107498:
#0  0x000000000285882b n/a (ghostty + 0x185882b)
#1  0x000000000285a888 n/a (ghostty + 0x185a888)
#2  0x000000000245dfb4 n/a (ghostty + 0x145dfb4)

Crash History (from coredumpctl)

Sat 2026-01-17 12:06:53  SIGSEGV  (version 20251229 - bundled fontconfig)
Tue 2026-01-20 16:03:45  SIGABRT  (version 20251229 - bundled fontconfig)
Tue 2026-01-20 16:22:10  SIGSEGV  (version 20251229 - bundled fontconfig)
Tue 2026-01-20 16:32:34  SIGSEGV  (version 20251229 - bundled fontconfig)
Fri 2026-01-23 06:08:59  SIGABRT  (version 20251229 - bundled fontconfig)
Fri 2026-01-23 15:12:55  SIGSEGV  (version 20251229 - bundled fontconfig)
Mon 2026-01-26 11:39:01  SIGSEGV  (version 20260122 - bundled fontconfig)
Mon 2026-01-26 12:43:50  SIGSEGV  (version 20260122 - bundled fontconfig)
Mon 2026-01-26 14:28:52  SIGSEGV  (version 20260122 - bundled fontconfig)
--- WORKAROUND APPLIED 2026-01-26 ~15:00 ---
(monitoring for crashes with system fontconfig build)

Workaround Test Results

Tested: Building with -fsys=fontconfig to use system fontconfig (2.17.0)

zig build -Doptimize=ReleaseFast -fsys=fontconfig

Result: Build successful. The binary now dynamically links to system fontconfig:

$ ldd zig-out/bin/ghostty | grep fontconfig
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1

Current test build: Ghostty 1.3.0-main+061a0ae56 (Jan 24, 2026)

Observations

1. Same call path: Crashes occur in the renderer thread during rebuildCells -> font shaping -> CodepointResolver -> Fontconfig.discover

2. Not Claude-specific: Crashes happen during various terminal activities, not exclusively with Claude

3. Cross-platform: I'm on AMD/Wayland vs original report's Ubuntu/X11/GNOME - suggests fontconfig interaction issue, not hardware-specific

4. Persists across versions: Crashes occurred on both 20251229 and 20260122 tip builds with bundled fontconfig

Code Analysis - Potential Root Causes

While investigating the source code, I identified a few potential issues that might be related:

1. Fontconfig Thread Safety (Most Likely)

The crash occurs when fontconfig is called from the renderer thread:

rebuildCells → font.shaper.run → CodepointResolver.getIndex → Fontconfig.discover

Fontconfig's FcConfigGetCurrent() and FcFontSort() are not thread-safe by default. The bundled fontconfig 2.14.2 may not be built with thread-safety enabled, while system fontconfig packages (2.17.0+) typically are built with --enable-thread-safe.

This would explain why -fsys=fontconfig works as a workaround.

2. Font Grid Lock Timing (generic.zig:1485-1490)

const modified = self.font_grid.atlas_grayscale.modified.load(.monotonic);
if (modified <= frame.grayscale_modified) break :texture;
self.font_grid.lock.lockShared();  // Lock acquired AFTER reading modified

The modified flag is read before acquiring the lock. If another thread modifies the atlas between reading the flag and acquiring the lock, there could be inconsistent state.

3. Atlas Resize Race Condition

In Atlas.grow(), the atlas data is reallocated. If the renderer thread is accessing atlas data while another thread triggers a resize (via new glyph rendering), there could be a use-after-free scenario.

Questions

1. Is the bundled fontconfig built with --enable-thread-safe? If not, could that be added to the build configuration?

2. Would it make sense to move font fallback discovery off the renderer thread entirely to avoid these thread-safety issues?

3. Should the font grid lock be acquired before checking the modified flag to prevent the race window?

---

[Will update with results after testing -fsys=fontconfig build for a few days]

---

Code Analysis & Theories

These are potential root causes identified during source code investigation. Useful for debugging if crashes continue.

Theory 1: Font Grid Race Condition (HIGH PROBABILITY)

Location: src/renderer/generic.zig:1485-1490

// CURRENT CODE - potential race condition
const modified = self.font_grid.atlas_grayscale.modified.load(.monotonic);
if (modified <= frame.grayscale_modified) break :texture;
self.font_grid.lock.lockShared();  // Lock acquired AFTER reading modified
defer self.font_grid.lock.unlockShared();
frame.grayscale_modified = self.font_grid.atlas_grayscale.modified.load(.monotonic);
try self.syncAtlasTexture(&self.font_grid.atlas_grayscale, &frame.grayscale);

Problem: The modified flag is read before acquiring the lock. Between reading the flag and acquiring the lock, another thread could:

1. Acquire exclusive lock on font_grid.lock
2. Call atlas.grow() which reallocates atlas.data
3. Release the lock

When we then acquire the shared lock and call syncAtlasTexture, we might be working with stale assumptions about the atlas state.

Potential Fix:

// Acquire lock FIRST, then check modified
self.font_grid.lock.lockShared();
defer self.font_grid.lock.unlockShared();
const modified = self.font_grid.atlas_grayscale.modified.load(.monotonic);
if (modified <= frame.grayscale_modified) break :texture;
// ... rest of code

---

Theory 2: Fontconfig Thread Safety (HIGH PROBABILITY)

Location: src/font/CodepointResolver.zig:175 and src/font/discovery.zig

Problem: Fontconfig is called from the renderer thread during font fallback discovery:

rebuildCells → font.shaper.run → CodepointResolver.getIndex → Fontconfig.discover

Fontconfig's FcConfigGetCurrent() and related functions are not thread-safe by default. The bundled fontconfig 2.14.2 may not be built with thread-safety enabled, while system fontconfig (2.17.0+) might be.

Evidence:

• Original crash backtrace shows crash in FcCompare called from FcFontSort
• Building with -fsys=fontconfig (system version) reportedly fixes the crash
• System packages are typically built with --enable-thread-safe

Potential Fixes:

1. Use system fontconfig (current workaround)
2. Rebuild bundled fontconfig with thread-safety flags
3. Add mutex around fontconfig calls in CodepointResolver
4. Move font discovery off the renderer thread

---

Theory 3: Image Placement Index Validation (MEDIUM PROBABILITY)

Location: src/renderer/generic.zig:1547-1586 (prepKittyGraphics)

Problem: In prepKittyGraphics, image placements are processed and indices are stored:

self.image_placements.appendAssumeCapacity(.{
    .image_id = img_id,
    .x = x,
    .y = y,
    // ...
});

If image_placements capacity is miscalculated or if there's concurrent modification, this could cause out-of-bounds access later in drawFrame.

---

Theory 4: errdefer unreachable Pattern (LOW PROBABILITY)

Location: src/renderer/generic.zig:1286 and others

errdefer comptime unreachable;

This pattern assumes certain error paths can never be taken at runtime. If an unexpected error occurs, this would cause a crash rather than graceful error handling.

---

Theory 5: Atlas Resize During Render (MEDIUM PROBABILITY)

Location: src/font/Atlas.zig:314 (grow function)

The grow() function reallocates atlas data:

pub fn grow(self: *Atlas, alloc: Allocator, size_new: u32) Allocator.Error!void {
    // ... allocates new data, copies old data, frees old data
    _ = self.modified.fetchAdd(1, .monotonic);
    _ = self.resized.fetchAdd(1, .monotonic);
}

If the renderer is reading atlas data while another thread triggers a resize (via glyph rendering that needs more space), there could be a use-after-free if locking isn't properly coordinated.

---

Summary Table

Theory	Location	Probability	Status
Font grid race condition	generic.zig:1485	HIGH	Needs verification
Fontconfig thread safety	CodepointResolver.zig	HIGH	Workaround applied
Image placement bounds	generic.zig:1547	MEDIUM	Unverified
errdefer unreachable	generic.zig:1286	LOW	Unlikely cause
Atlas resize race	Atlas.zig:314	MEDIUM	Needs verification

[jcollie]

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

[mitchellh]

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.

[krk]

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?

[peterzandbergen]

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.