Appli Flatpak figée au lancement ? 7 étapes jusqu'au cache de polices empoisonné

🧠 Synthèse visuelle et chronologie

Voici la carte complète avant d'entrer dans le détail. Elle sert de feuille de route à l'enquête qui suit.

🌐 APPLI FLATPAK QT5 « FIGÉE » AU LANCEMENT
│
├── 🚨 SYMPTÔME
│   ├── Fenêtre jamais affichée, processus visible ~1 min
│   └── Aucun message d'erreur
│
├── ⚠️ RÉALITÉ SYSTÈME
│   ├── SIGSEGV à chaque lancement (core dump)
│   └── Le « gel » = l'écriture du core dump (wchan : vfs_coredump)
│
├── 🔍 CAUSE IMMÉDIATE
│   └── fontconfig 2.17.1 (runtime Flatpak) lit un cache au format v12
│       └── via un lien <hash>-le64.cache-9 → <hash>-le64.cache-12
│
├── 🧬 CAUSE RACINE
│   └── sharp-libvips (fontconfig 2.18.3 embarqué)
│       └── écrit des caches v12 + des liens de rétrocompatibilité
│           dans ~/.cache/fontconfig, partagé avec les Flatpaks
│
└── 🛠️ RÉPONSE
    ├── Correctif : archiver les 42 liens empoisonnés
    └── Prévention : garde systemd (.path) qui archive tout nouveau lien

La chronologie reconstituée

1. 16/08/2026fontconfig 2.18.1 est installé sur l'hôte. Il écrit ses caches au format v10 : nous verrons qu'il est innocent.
2. 25/09/2026Chromium 154 est installé. Fausse piste tentante (un bug Chrome 154 est signalé ailleurs), mais le paquet openSUSE utilise le fontconfig du système.
3. 27/09/2026 · 04:1514 fichiers de cache v12 et 42 liens cache-9/10/11 → cache-12 apparaissent dans ~/.cache/fontconfig.
4. 30/09/2026 · 13:11Mise à jour de l'application : elle bascule sur le runtime org.kde.Platform 5.15-25.08, qui embarque fontconfig 2.17.1.
5. 02/10/2026 · 18:09Premier lancement après la mise à jour : premier SIGSEGV. Tous les suivants plantent aussi.
6. 05/10/2026Diagnostic complet, correctif, puis pose d'une garde automatique.

Le poison était en place trois jours avant la mise à jour qui l'a rendu mortel. C'est typique : deux changements anodins, à des jours d'écart, sans lien apparent.

🧭 Étape 1 : identifier l'application et son runtime

Premier réflexe avec un Flatpak : savoir quel runtime il utilise. C'est lui, et non votre distribution, qui fournit Qt, fontconfig, la glibc et la plupart des bibliothèques.

flatpak list --app | grep -i 4ktube
flatpak info com.warlordsoftwares.youtube-downloader-4ktube
flatpak info --show-permissions com.warlordsoftwares.youtube-downloader-4ktube

⏱️ Étape 2 : figée ou mourante ? Lire l'état du processus

On lance l'application en arrière-plan, puis on interroge le noyau sur l'état du processus et sur la fonction noyau où il attend (wchan).

flatpak run com.warlordsoftwares.youtube-downloader-4ktube &
sleep 30
ps -o pid,stat,etime,time,wchan:25,cmd -p "$(pgrep -f '[4]ktube.py')"

  PID STAT  ELAPSED     TIME WCHAN                  CMD
37866 DN      00:35 00:00:03 folio_wait_bit_common  python3 /app/4ktube/4ktube.py
… 70 secondes plus tard :
37866 SNl     01:42 00:00:13 vfs_coredump           python3 /app/4ktube/4ktube.py

La deuxième ligne dit tout : vfs_coredump est la fonction du noyau qui écrit le core dump d'un processus qui vient de planter. Le « gel » n'était que cette écriture, ralentie par une machine saturée. L'application était déjà morte.

💥 Étape 3 : faire parler les core dumps

Sur un système avec systemd, chaque plantage est archivé par systemd-coredump. Deux commandes suffisent pour une première lecture (sorties abrégées).

coredumpctl list --no-pager | grep -i python
coredumpctl info <PID> --no-pager

Fri 2026-10-02 18:09:53 CEST  68128 1000 1000 SIGSEGV present  /usr/bin/python3.13  39.7M
Fri 2026-10-02 18:15:57 CEST  70100 1000 1000 SIGSEGV present  /usr/bin/python3.13  30.2M
Mon 2026-10-05 18:56:50 CEST  37164 1000 1000 SIGSEGV present  /usr/bin/python3.13  31.1M
Mon 2026-10-05 18:58:08 CEST  37866 1000 1000 SIGSEGV present  /usr/bin/python3.13    31M
        Signal: 11 (SEGV) si_code: SI_KERNEL
  Command Line: python3 /app/4ktube/4ktube.py
                #0 libfontconfig.so.1.16.0 + 0xc26f
                #1 libQt5WaylandClient.so.5.15.18 + 0xb1456

Trois informations décisives :

• Le plantage est systématique : chaque lancement depuis le 2 octobre produit un core dump.
• Le premier date du 2 octobre à 18:09 : une date à corréler avec les mises à jour.
• La pile s'arrête dans fontconfig, appelé par le module Wayland de Qt. Le si_code SI_KERNEL indique une faute de protection générale, souvent le signe d'un pointeur aberrant.

🔗 Étape 4 : corréler avec les mises à jour Flatpak

L'historique de zypper ne montre pas les mises à jour Flatpak. Elles ont leur propre journal.

flatpak history --columns=time,change,application,branch | tail -n 15

sept. 30 13:04:22  deploy install  org.kde.KStyle.Adwaita                          5.15-25.08
sept. 30 13:04:28  deploy install  org.kde.Platform.Locale                         5.15-25.08
sept. 30 13:09:50  deploy install  org.kde.Platform                                5.15-25.08
sept. 30 13:11:35  deploy install  com.warlordsoftwares.youtube-downloader-4ktube  stable

Le 30 septembre, l'application a été redéployée sur un runtime neuf. Comparons alors le fontconfig du runtime à celui de l'hôte :

flatpak run --command=fc-match com.warlordsoftwares.youtube-downloader-4ktube --version
rpm -q fontconfig

Deux versions différentes de la même bibliothèque, qui partagent des répertoires de cache : la piste se resserre.

🔬 Étape 5 : changer une seule couche, puis lire la vraie pile

5a. Wayland ou X11 ?

La pile mentionne le module Wayland de Qt. Avant d'accuser Wayland, on change cette seule couche et on relance sous X11 (XWayland) :

flatpak run --socket=x11 --nosocket=wayland --env=QT_QPA_PLATFORM=xcb com.warlordsoftwares.youtube-downloader-4ktube

        Signal: 11 (SEGV) si_code: SI_KERNEL
                #0 libfontconfig.so.1.16.0 + 0xc26f
                #1 libQt5XcbQpa.so.5.15.18 + 0xbc5b6

Même plantage, même adresse dans fontconfig : seul l'appelant change. Wayland est innocent ; le problème est dans fontconfig ou dans ce qu'il lit.

5b. Le piège du « symbole le plus proche »

Tentation classique : chercher, avec nm -D, le symbole exporté le plus proche de l'offset 0xc26f. Résultat : FcCharSetDestroy + 0xcf. C'était faux : la fonction réellement en cause est interne (non exportée), et l'outil a simplement rendu le dernier symbole public qui la précède.

5c. La vraie pile, avec gdb et un sysroot Flatpak

Les bibliothèques du core dump ont des chemins internes au sandbox (/usr/lib/x86_64-linux-gnu/…). On reconstruit donc un « sysroot » fait de liens vers le runtime et l'application, puis on le donne à gdb :

RT=/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.15-25.08/active/files
APP=/var/lib/flatpak/app/com.warlordsoftwares.youtube-downloader-4ktube/x86_64/stable/active/files
mkdir -p ~/sysroot
ln -sfn "$RT" ~/sysroot/usr
ln -sfn "$APP" ~/sysroot/app
ln -sfn usr/lib ~/sysroot/lib
ln -sfn usr/lib ~/sysroot/lib64
coredumpctl dump <PID> -o ~/core.4ktube
gdb -q -batch -nx -ex "set sysroot $HOME/sysroot" -ex "set debuginfod enabled off" \
    -ex "core-file $HOME/core.4ktube" -ex "bt 30" ~/sysroot/usr/bin/python3.13

1. #0FcCharSetFindLeafForwardlibfontconfig
2. #1FcCharSetHasCharlibfontconfig
3. #3QFontEngineMulti::stringToCMaplibQt5Gui
4. #4QTextEngine::shapeTextlibQt5Gui
5. #13QTextDocument::setHtmllibQt5Gui
6. #18QLabel::sizeHintlibQt5Widgets
7. #26QLayout::activatelibQt5Widgets
8. #27QWidgetPrivate::setVisiblelibQt5Widgets

Pile du core dump du test X11 (extrait). Lue de bas en haut, l'histoire devient limpide : au moment d'afficher la fenêtre, Qt calcule la taille d'une étiquette au texte riche, met ce texte en forme et demande à fontconfig si une police de secours contient tel caractère (FcCharSetHasChar). fontconfig parcourt alors la table des caractères de la police… et lit de la mémoire qui n'a aucun sens. Ces tables de caractères proviennent du cache de polices.

🧪 Étape 6 : réfuter, puis trouver le poison

Une première hypothèse, écartée

Où le sandbox cherche-t-il ses caches ?

flatpak run --command=sh com.warlordsoftwares.youtube-downloader-4ktube -c \
  'grep -h -o "<cachedir[^<]*</cachedir>" /etc/fonts/conf.d/50-flatpak.conf'

<cachedir>/usr/lib/fontconfig/cache</cachedir>
<cachedir>/app/cache/fontconfig</cachedir>
<cachedir prefix="xdg">fontconfig</cachedir>
<cachedir>/run/host/fonts-cache</cachedir>
<cachedir>/run/host/user-fonts-cache</cachedir>

/run/host/user-fonts-cache n'est autre que le ~/.cache/fontconfig de l'utilisateur sur l'hôte, monté en lecture dans le sandbox. Ce partage est voulu : c'est la configuration livrée avec le runtime, et elle évite à chaque application de réindexer les polices de l'hôte.

Ce qu'il y trouve

Sortie abrégée (empreintes raccourcies) :

find ~/.cache/fontconfig -maxdepth 1 -type l -printf '%TY-%Tm-%Td %TH:%TM  %f -> %l\n' | head -n 3
find ~/.cache/fontconfig -maxdepth 1 -type l | wc -l

2026-09-27 04:15  8e3a56fb…-le64.cache-9  -> 8e3a56fb…-le64.cache-12
2026-09-27 04:15  8e3a56fb…-le64.cache-10 -> 8e3a56fb…-le64.cache-12
2026-09-27 04:15  8e3a56fb…-le64.cache-11 -> 8e3a56fb…-le64.cache-12
42

42 liens symboliques (14 caches × 3 anciens formats) qui font passer un fichier v12 pour un fichier v9, v10 ou v11. Pour en avoir le cœur net, on lit l'en-tête binaire de chaque type de fichier : quatre octets de signature, puis quatre octets de version.

python3 - <<'EOF'
import glob, os, struct
for motif in ('*.cache-12', '*reindex1-10'):
    f = sorted(glob.glob(os.path.expanduser('~/.cache/fontconfig/' + motif)))[0]
    magic, version = struct.unpack('<Ii', open(f, 'rb').read(8))
    print(motif, hex(magic), 'version =', version)
EOF

*.cache-12 0xfc02fc04 version = 12
*reindex1-10 0xfc02fc04 version = 10

La preuve est matérielle : derrière le nom cache-9 se trouve un contenu au format 12. Le fontconfig 2.17.1 du runtime suit le lien et lit des structures qu'il ne sait pas interpréter — c'est exactement le mécanisme décrit dans un rapport public sur un autre logiciel (voir les sources).

🕵️ Étape 7 : démasquer l'écrivain

Qui, sur cette machine, sait écrire un cache fontconfig v12 ? On passe les candidats en revue, preuve à l'appui.

Le fichier versions.json de sharp-libvips annonce un fontconfig 2.18.3 compilé dans la bibliothèque. Pour le prendre la main dans le sac sans toucher au vrai cache, on lui fait dessiner du texte en lui donnant un cache isolé :

cd /chemin/vers/un/projet-node-avec-sharp
XDG_CACHE_HOME=/tmp/fc-test node -e "require('sharp')(Buffer.from('<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"200\" height=\"50\"><text x=\"5\" y=\"30\">Test</text></svg>')).png().toBuffer().then(() => console.log('rendu OK'))"
ls /tmp/fc-test/fontconfig | sed -E 's/^[0-9a-f]+-le64\.//' | sort | uniq -c

     14 cache-12
      1 CACHEDIR.TAG

Quatorze fichiers v12, exactement le nombre trouvé le 27 septembre. L'écrivain est identifié. Deux points restent honnêtement ouverts :

• dans un dossier vide, sharp n'a créé aucun lien : les liens de rétrocompatibilité apparaissent quand d'anciens caches existent déjà, comme le décrit le rapport cité en sources — nous ne l'avons pas reproduit ;
• le processus exact qui a lancé sharp le 27 septembre à 04:15 n'a pas été identifié.

🛠️ Le correctif : archiver les liens empoisonnés

Inutile de toucher à l'application ou au runtime : il suffit de retirer les liens. On les archive plutôt que de les supprimer, pour pouvoir revenir en arrière.

mkdir -p ~/archives/fontconfig-cache12/liens
find ~/.cache/fontconfig -maxdepth 1 -type l -lname '*cache-12' -exec mv -n {} ~/archives/fontconfig-cache12/liens/ \;
ls ~/archives/fontconfig-cache12/liens | wc -l

42

Les 14 fichiers cache-12 restent en place : seul un lecteur v12 les ouvre. Privé de ses liens, le runtime 2.17.1 ne trouve plus de faux cache v9, régénère son propre cache dans le répertoire de l'application, et tout rentre dans l'ordre.

Vérification

flatpak run com.warlordsoftwares.youtube-downloader-4ktube &
sleep 120
coredumpctl list --no-pager --since "-3min"

No coredumps found.

Une alternative plus radicale circule : vider entièrement ~/.cache/fontconfig puis lancer fc-cache -f. Elle fonctionne aussi, mais détruit des caches sains, et le poison reviendra au prochain passage de sharp.

🛡️ La prévention : une garde systemd

Tant qu'un programme embarquant un fontconfig récent écrit dans ~/.cache/fontconfig, les liens peuvent revenir. Plutôt que de surveiller chaque outil, on surveille le dossier : une unité .path de systemd déclenche un petit script dès que son contenu change.

Le script

#!/bin/bash
# ~/.local/bin/fontconfig-cache12-guard.sh
# Archive les liens <hash>-le64.cache-{9,10,11} -> *.cache-12 (poison pour les lecteurs fontconfig v9).
set -u
SRC=${FCG_SRC:-$HOME/.cache/fontconfig}
AR_ROOT=${FCG_AR:-$HOME/archives}
[ -d "$SRC" ] || exit 0
mapfile -d '' liens < <(find "$SRC" -maxdepth 1 -type l -lname '*cache-12' -print0)
[ "${#liens[@]}" -eq 0 ] && exit 0
DEST="$AR_ROOT/$(date +%Y-%m-%d)_fontconfig_liens_cache12/$(date +%H%M%S)_$$"
mkdir -p "$DEST" || exit 1
n=0
for l in "${liens[@]}"; do
    mv -n -- "$l" "$DEST/" && [ ! -L "$l" ] && n=$((n + 1))
done
echo "fontconfig-guard: ${n}/${#liens[@]} lien(s) archivé(s) dans $DEST"
[ "$n" -eq "${#liens[@]}" ]

Les deux unités systemd (utilisateur)

# ~/.config/systemd/user/fontconfig-cache12-guard.path
[Unit]
Description=Garde fontconfig : surveille ~/.cache/fontconfig (liens -> cache-12)
[Path]
PathChanged=%h/.cache/fontconfig
Unit=fontconfig-cache12-guard.service
[Install]
WantedBy=default.target
# ~/.config/systemd/user/fontconfig-cache12-guard.service
[Unit]
Description=Garde fontconfig : archive les liens -> cache-12
[Service]
Type=oneshot
ExecStart=/usr/bin/bash %h/.local/bin/fontconfig-cache12-guard.sh
[Install]
WantedBy=default.target

bash -n ~/.local/bin/fontconfig-cache12-guard.sh
systemd-analyze --user verify ~/.config/systemd/user/fontconfig-cache12-guard.{service,path}
systemctl --user daemon-reload
systemctl --user enable fontconfig-cache12-guard.service fontconfig-cache12-guard.path
systemctl --user start fontconfig-cache12-guard.path

Le .service est aussi activé à l'ouverture de session : un passage de contrôle a lieu même si des liens sont apparus pendant que la garde ne tournait pas.

Tester avant de faire confiance

Le script a d'abord été éprouvé sur un dossier témoin (variables FCG_SRC et FCG_AR) : dossier sans lien, trois liens à archiver mêlés à des fichiers et à un lien qui ne doivent pas bouger, relance sans effet, dossier absent. Puis, une fois la garde branchée, un témoin réel (chemins de sortie adaptés à la version générique du script) :

ln -s TEMOIN-le64.cache-12 ~/.cache/fontconfig/TEMOIN-le64.cache-9
sleep 2
ls ~/.cache/fontconfig/TEMOIN* 2>/dev/null || echo "témoin archivé"
journalctl --user -u fontconfig-cache12-guard.service -n 3 --no-pager

témoin archivé
fontconfig-guard: 1/1 lien(s) archivé(s) dans ~/archives/2026-10-05_fontconfig_liens_cache12/193511_54755

🎯 Qui est concerné ?

Le scénario demande deux ingrédients, et chacun est courant.

Vérification en une ligne — si le résultat n'est pas zéro, vous êtes exposé :

find ~/.cache/fontconfig -maxdepth 1 -type l -lname '*cache-12' | wc -l

📚 Ce que cette panne enseigne

🏁 Conclusion

🔗 Sources et références

• orca #23205 — sharp-libvips écrit un cache fontconfig v12 et des liens cache-9/10/11, faisant planter les applications Qt/KDE
• KDE Bug 525636 — plasmashell plante dans FcCharSetFindLeafForward au démarrage
• Google Issue Tracker 565132857 — Chrome 154 crée des liens cache-9 vers cache-12 ; Plasma plante
• sharp-libvips — binaires libvips précompilés utilisés par sharp
• fontconfig — page officielle du projet (freedesktop.org)
• systemd.path — documentation officielle des unités de surveillance de chemin
• coredumpctl — documentation officielle
• Documentation officielle de Flatpak

📖 Articles recommandés