[Crash]: Black screen on startup and crash (flatpak build)

[CyberHippy1991]

Version of OpenTTD

ver 12.2, Linux Mint 20

Steps to reproduce

When trying to launch OpenTTD, a black screen appears and the game closes. OpenTTD is installed via flatpak.

If I run the game via console with the command "flatpak run org.openttd.OpenTTD" I get the error "dbg: [freetype] Font is missing glyphs to display char 0x43D in medium font size
openttd: ../../src/fccache.c:808: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
Crash encountered, generating crash log..." and a log is generated.

Reinstalling the package didn't help.

Upload crash files

crash20221212222537.log

crash20221212222537.sav.zip
crash20221212222545.log

crash20221212222545.sav.zip

[PeterN]

Possible duplicate of #10053?

[CyberHippy1991]

Not sure. I tried deleting the config folder, which is located along the path /home/user/.var/app/org.openttd.OpenTTD/ and even the org.openttd.OpenTTD folder, after uninstalling the game via the flatpak uninstall flathub org.openttd.OpenTTD command. After reinstalling, the problem remained. In the config folder, the openttd.cfg file is not created.

But I didn’t understand how in that request they forced the game to run through x11. When installed in the console, it shows that it uses only x11.

/var/lib/flatpak/app/org.openttd.OpenTTD/current/active/export/bin in the org.openttd.OpenTTD file, I tried adding the --socket=x11 argument, but it didn't help.

crash20221213183347.log

crash20221213183347.sav.zip

[PeterN]

Yes, that wasn't really a satisfactory resolution on the other report. Seems likely to be the same cause though.

[tpetazzoni]

Same problem here on Fedora 37, but only when I specify a custom small_font, medium_font or large_font in the config file. When these settings are empty, the game works fine, just with an ugly (and too small) font.

[James103]

but only when I specify a custom small_font, medium_font or large_font in the config file

Does this affect the usage of a custom font at all, or only for certain custom fonts?

When you change the language used in the game, the font may automatically change to match the new language (if not set explicitly). Does this crash the game (either immediately or on next startup)?

[tpetazzoni]

So far, I've tried 3 different fonts, and for all of them, I encountered the problem. I have not tried changing the language.

[SuborbitalPigeon]

Running fc-list from inside any flatpak shell (flatpak run --command=bash org.openttd.OpenTTD) causes a crash too.

If I run fc-cache outside of the flatpak first, everything works fine.

Found https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/329 and https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/161 which could be related.

[senseiski]

Same problem here on Fedora 37, but only when I specify a custom small_font, medium_font or large_font in the config file. When these settings are empty, the game works fine, just with an ugly (and too small) font.

@tpetazzoni I've found a workaround - in openttd.cfg you need to set the fonts not with direct path to /usr/share/fonts but as an example here:
small_font = /run/host/fonts/truetype/ubuntu/Ubuntu-R.ttf
medium_font = /run/host/fonts/truetype/ubuntu/Ubuntu-R.ttf
large_font = /run/host/fonts/truetype/ubuntu/Ubuntu-R.ttf
mono_font = /run/host/fonts/truetype/ubuntu/UbuntuMono-B.ttf

I found this based on the output of running "flatpak run --command=fc-list org.openttd.OpenTTD" (it crashed, but threw a long log with my system fonts)

[tpetazzoni]

OpenTTD 13.1 is still affected by this issue on Wayland.

[JohnTheCoolingFan]

Still having this problem and can't use any of the workarounds/fixes from here

[TrueBrain]

Would you mind trying our official linux build and attach here any crash.log it might generate? Tnx!

https://www.openttd.org/downloads/openttd-nightlies/latest.html

[JohnTheCoolingFan]

@TrueBrain that build does work correctly, I've noticed it's using x11. So I enabled X11 access in Flatseal for Openttd and it's launching correctly. Is wayland supported officially?

[TrueBrain]

@TrueBrain that build does work correctly, I've noticed it's using x11. So I enabled X11 access in Flatseal for Openttd and it's launching correctly. Is wayland supported officially?

Tnx. With this information we can reproduce it locally, which means it is more likely we can find a fix. The problem with many of these Linux reports is that they evolve around flatpak, and we never know where the actual problem is :) But now we know .. now to see what actually goes wrong ;)

[TrueBrain]

This is one weird issue.

What seems to happen is this:

• Wayland-client uses Pango for what-ever reason
• On start-up, Wayland initializes Pango, which initializes FontCache
• We also use FontCache
• FontCache has a shared instance, common between all threads
• Pango made in 2020 an optimization, where they move FontConfig to a thread

So what we end up with is this:

• Wayland starts, Pango starts, thread is created
• Thread starts FontConfig
• We start FontConfig
• Thread finishes FontConfig
• <and here the shared instance is deleted>
• We continue ... with the .. deleted FontConfig?

In result, the assert above. The problem happens earlier, but the assert captured it.

The problem here is: there is nothing we can do. Pango has all functions related to this as static, meaning we cannot hook into them, or even see if the thread finished. FontConfig has no way to tell us if someone else already initialized the configuration.

FontConfig does some ref-counting, but not for calls to FcInit, which is used by both us and pango to initialize FontConfig.

Yeah .... this is going to require some creativity .... this is really fucked up :D

PS: FontConfig claims to be "thread-safe", but their definition and mine differ. You can use FontConfig from different threads, but there is a single instance of FontConfig shared among the threads. Most likely makes total sense for them .. but when a library (pango in this case) initializes FontConfig and an application .. you seem to be screwed.

Mostly, I cannot really believe FontConfig refcounts a lot of things, but doesn't refcount FcInit :P

Anyway, I might be wrong, it isn't the easiest code to read .. so some references:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fccfg.c#L89
https://github.com/GNOME/pango/blob/main/pango/pangofc-fontmap.c#L1363

And we will continue to look for a solution ..