Repository navigation
font rendering segv/panic rendering certain (pot. libgallium issue?) #10568
Replies: 4 comments 2 replies
|
I'm getting what looks to be the same crash with 1.3.1, there's a workaround by adding fonts to the config, e.g. Here's my trace: |
|
I've tried to debug this a bit with assistance from Claude. I'm not sure how useful this may be but I've validated what's here is accurate to the best of my knowledge. This is the summary of where I got to: The crash
What triggers it
Debug log output preceding the crash Confirmed NOT the cause
Still unknown
|
|
Idk if you have fixed it, but the solution is to link the system fontconfig -fsys=fontconfig Still have no clue what caused it.. Seems to be related to how something in fontconfig allocates, because rendering ant "fat" characters like cjs chars before prevents the issue. Weird thing is however i had not updated ghostty in months when it first occured, nor fontconfig. Given that the memory issue stemmed from libgallium.. i blame it.. |
|
After more time with Claude I think we've established the root cause and a potential fix, here's a rundown from Claude. I'm really not an expert in this area but I've verified the change prevents the crash on my machine and the explanation makes sense from what was observed and some more reading around the subject. I can raise a PR for the fix (it's essentially 1 line in the library build.zig) but not confident it wouldn't cause issues on other platforms. Root cause
Those same cache pages are later accessed by Ghostty's renderer thread during fallback The crash was intermittent because it required a race between the munmap (triggered by How we identified it
The combination of these tools made the interposition chain unambiguous. How the fix works Adding When |
|
The symbol-interposition theory is very plausible, and it is easy to prove or disprove without relying on timing. Check whether the bundled fontconfig symbols are exported from the main executable: readelf -Ws ./ghostty | grep -E ' Fc(ConfigSubstitute|FontSort|FontSetSort|Compare)'If they show up as
|
|
If the issue is because Ghostty statically links Fontconfig, do note that the easiest fix is compiling Ghostty with |
Uh oh!
There was an error while loading. Please reload this page.
Issue Description
When rendering certain charachters(not specific ones), it leads to a segegv.
The issue is not related to a specific font or char, rather the sequence.
As a example, one case which crashed 100% of the times, was able to proceed if first rendering a cjs char, possibly due to padding.
dmsg shows libgallium trying to access unmapped gpu memory.
The issue persists between multiple ghostty versions, including current main branch, and seems to be more of a driver bug than ghostty specific, although any other application handles it.
Expected Behavior
Error should be handled before leading to a crash.
Actual Behavior
Segegv / panic if -Doptimize=ReleaseSafe
Reproduction Steps
Ghostty Logs
syslog:
OS Version Information
Ubuntu 25.10
(Linux only) Display Server
Wayland
(Linux only) Desktop Environment/Window Manager
GNOME 48
Minimal Ghostty Configuration
Additional Relevant Configuration
GTK_DEBUG=interactive
GTK verbose logs
I acknowledge that:
```) on separate lines.All reactions