Patch partially addresses this question from last month:
https://lists.suckless.org/dev/1708/32111.html
If a Glyph simply does not exist within the fonts of a system,
fontconfig ends up returning the original default font again. At this
point, 'st' happily opens it again, and holds a new frc array slot
hostage with a duplicate opened font in the array. Same glyph, it
won't happen again, but for a different glyph that doesn't exist,
things get really crazy with opens and closes (especially once the
hard-coded 16 fallback cache limit is reached). Under a certain mix
of legitimate fonts on the screen, it's possible to close a font that
is actually being used (This never works out well).
I attached a fairly simple diff that stops this.
Check-in comment:
If fontconfig returns a font that has no matching glyph, close the now
opened, unused font.
I first started to investigate a problem under macOS that happens
because macOS actually has a fallback font. There, once any single
Glyph cannot be found at all, no other Glyph that had not already been
loaded will ever be looked up. This, because the loaded fallback font
will ALWAYS return a positive Glyph. In addition to the fix attached,
the fix for this under macOS seems to be in .fonts.conf, so I won't
bother with further details. (Feel free to reach out off-list if you
want more info).
Thank you,
Gary Allen
--- a/x.c 2017-09-30 15:46:51.713848500 -0400
+++ b/x.c 2017-10-01 16:59:13.786729400 -0400
@@ -1100,8 +1100,13 @@
glyphidx = XftCharIndex(xw.dpy, frc[frclen].font, rune);
- f = frclen;
- frclen++;
+ if (!glyphidx) {
+ XftFontClose(xw.dpy, frc[frclen].font);
+ frc[frclen].unicodep = 0;
+ } else {
+ f = frclen;
+ frclen++;
+ }
FcPatternDestroy(fcpattern);
FcCharSetDestroy(fccharset);
