appimage stop working, system monitor show is running but wont open the ui windows, on zorin os

[JohnTheDraftsman]

What happened?

i find out the the morning after using it, at boot a silent upgrade was run by zorin going from 2:21.1.12-1ubuntu1.6, to 2:21.1.12-1ubuntu1. 8

hello, until yesterday morning it was working fine and was using forge neo, wan2gp, looking at comfy to learn to use it , stopped the packages, closing SM , turn off pc, since then double click, right button>run, or from terminal seems to launch, but wont open the window ui, other appimages like krita work fine, libfuse up to date, so i dont think is an issue with fuse or lib, or zorin ( on xorg) , tried delete and reinstall latest update, to install from scratch, same thing, i'm lost, wasted most of my day trying to find the cause and fix it, no dice, Lykos, if you read this, help, love SM,

Steps to reproduce

1. open the mnt where is installed
2. double click on appimage, or right button> run
3. nothing happens, on system monitor shows the app running,
4. in terminal no bugs where found, other appimages work fine.

Relevant logs

``Start-Date: 2026-09-27 22:38:09
Commandline: aptdaemon role='role-commit-packages' sender=':1.198'
Upgrade: dmidecode:amd64 (3.5-3ubuntu0.1, 3.5-3ubuntu0.2), libaudit-common:amd64 (1:3.1.2-2.1build1.1, 1:3.1.2-2.1ubuntu0.1), xserver-xorg-core:amd64 (2:21.1.12-1ubuntu1.6, 2:21.1.12-1ubuntu1.8), libpciaccess0:amd64 (0.17-3ubuntu0.24.04.2, 0.17-3ubuntu0.24.04.3), libpciaccess0:i386 (0.17-3ubuntu0.24.04.2, 0.17-3ubuntu0.24.04.3), apparmor:amd64 (4.0.1really4.0.1-0ubuntu0.24.04.7, 4.0.1really4.0.1-0ubuntu0.24.04.8), python3-requests:amd64 (2.31.0+dfsg-1ubuntu1.1, 2.31.0+dfsg-1ubuntu1.2), libapparmor1:amd64 (4.0.1really4.0.1-0ubuntu0.24.04.7, 4.0.1really4.0.1-0ubuntu0.24.04.8), libapparmor1:i386 (4.0.1really4.0.1-0ubuntu0.24.04.7, 4.0.1really4.0.1-0ubuntu0.24.04.8), dracut-install:amd64 (060+5-1ubuntu3.3, 060+5-1ubuntu3.4), xserver-xorg-legacy:amd64 (2:21.1.12-1ubuntu1.6, 2:21.1.12-1ubuntu1.8), xserver-common:amd64 (2:21.1.12-1ubuntu1.6, 2:21.1.12-1ubuntu1.8), xserver-xephyr:amd64 (2:21.1.12-1ubuntu1.6, 2:21.1.12-1ubuntu1.8), brave-browser:amd64 (1.95.104, 1.96.59), libaudit1:amd64 (1:3.1.2-2.1build1.1, 1:3.1.2-2.1ubuntu0.1), linux-firmware-amd-graphics:amd64 (20240318.git3b128b60-0ubuntu3.2, 20240318.git3b128b60-0ubuntu3.3)
End-Date: 2026-09-27 22:38:2

### Version

v2.16.4

### What Operating System are you using?

Linux

[JohnTheDraftsman]

Solved it, on a zorin post 24hs ago someone was having the same issue, the issue is from the major Webkit migration introduced by Canonical. many distros have zero problem, including Zorin users, but some had the same head scratching problem i had. I run the command given there in the terminal, i'll leave it here in case someone else came looking for the same issue, and maybe be of help to Lykos

rm -rf ~/.cache/fontconfig
fc-cache -fv

and the appimage started normally, immense thanks to Neural_fault on SM Discord who went into a rabbit hole after spending a full afternoon trying to help, He find out a post that explains it : "Brave issue #59380: "Bundled fontconfig overwrites system ~/.cache/fontconfig cache-9 files with empty stubs; breaks WebKitGTK apps." Environment line reads Zorin OS / Ubuntu 24.04. Brave statically links its own newer fontconfig; the distro ships 2.15.0 (cache version 9). On every launch Brave writes a valid -le64.cache-12 plus 46-byte stub files named cache-9, cache-10, cache-11.

Chromium issue #565475896: "Chrome 154 bundled fontconfig writes cache-12 files plus cache-9/10/11 symlinks into ~/.cache/fontconfig." The system fontconfig "looks for -le64.cache-9, follows the symlink and memory-maps a format-12 file as if it were format 9. It then crashes as soon as it reads charsets: FcCharSetHasChar." Confirmed on Ubuntu and Fedora 44.

Codex issue #48217: same layout, "121 real *-le64.cache-12 files, 363 symlinks," Plasma crashing with 0xfefefefefefefefe passed to FcCharSetHasChar.
when that chromium build is launched it overwrites the fontcache with format-12, and symlinks format-9 and above to it. So if fontconfig is not updated enough (still uses format-9), or an application tries to load it as format-9... they hang/crash
reason some wouldn't be effected is if the app bundles its own fontconfig internally... like electron apps do
Brave writes empty 46-byte stubs → consumers see zero fonts → WebKitGTK/SkiaSharp spins or hangs. "ghost launch." SM heavily uses SkiaSharp SM → Avalonia Skia backend → SkiaSharp → libSkiaSharp.so → fontconfig → ~/.cache/fontconfig

Chrome/Codex write symlinks to cache-12 → consumers mmap format-12 as format-9 → SIGSEGV in FcCharSetHasChar.

So.. not a bug, some weird bad luck on my side, Thanks for your amazing work,