CrealityPrint Linux AppImage aborts on every startup via std::terminate right after wxLocale init — reproduces across 7.0.0, 7.1.1, and 7.2.1 #607

Activity

1. pykekaisora commented on Sep 6, 2026

   

   pykekaisora

   on Sep 6, 2026

   More actions

   Hi there, I just reinstalled Omarchy Quattro to have a clean experience. I did have an error regarding fonts as well. can you try and run the command given and see if it helps you too?

   gsettings set org.gnome.desktop.interface font-name 'Noto Sans 11'
   
2. dellipse commented on Sep 12, 2026

   

   dellipse

   on Sep 12, 2026

   More actions

   I can confirm this exact crash independently on Omarchy + Hyprland as well, and have some additional data that might help narrow down the cause.

   Confirmed across two separate distributions of the same build (7.2.1.5476), both crashing identically, 100% reproducible on every launch, before the main window ever appears:

   • AUR creality-print-bin package (native install to /opt/creality-print)
   • Official upstream AppImage (CrealityPrint-V7.2.1.5476-x86_64-Release.AppImage, downloaded directly from this repo's releases)

   Fuller backtrace — I had the creality-print-bin-debug package installed locally, which resolved function names past frame #4:

   abort()
   std::terminate()
   Slic3r::GUI::Plater::priv::~priv()
   Slic3r::GUI::Plater::~Plater()
   wxWindowBase::DestroyChildren()
   wxWindow::~wxWindow()
   Notebook::~Notebook()
   wxWindowBase::DestroyChildren()
   wxWindow::~wxWindow()
   Slic3r::GUI::MainFrame::MainFrame()   <- still inside the constructor
   Slic3r::GUI::GUI_App::on_init_inner(bool)
   Slic3r::GUI::GUI_App::OnInit()
   

   So the exception/terminate happens while MainFrame's constructor is still building child windows — the stack is already unwinding through Notebook/Plater destruction when std::terminate() fires. My captured stderr on both crashes reads terminate called without an active exception (not "after throwing an instance of ..."), which usually points to a std::thread (or similar joinable RAII handle) being destroyed while still joinable, rather than a plain thrown exception. I can't name the exact object without full DWARF line tables, but this is a more specific lead than "an exception was thrown somewhere."

   Window-manager correlation (from the separate creality-print-bin AUR package's comment thread): other users report the identical crash under sway and qtile (both tiling), while it works under Plasma on X11 or Wayland (floating). That matches what we're both seeing on Hyprland — also a dynamic tiling Wayland compositor. This looks like a tiling-vs-floating WM incompatibility rather than anything Arch/Omarchy-specific.

   Most actionable data point: on this same machine, the official Linux Flatpak (CrealityPrint-Linux-flatpak_V7.2.1-Release_x86_64.flatpak, same 7.2.1.5476 build) does not crash — it launches cleanly under Hyprland, full main window and all. The only difference is the GNOME 50 Flatpak runtime sandboxing the GTK/wxWidgets stack vs. the AppImage/native build talking to the host compositor directly. That narrows the search space considerably — whatever differs between "GTK/wx inside the Flatpak's GNOME Platform sandbox" and "GTK/wx talking directly to a tiling Wayland compositor" is likely where this lives. One plausible link: your debug log's add_msg_content invalid font detected ... dark_mode=true line right before the crash — a Flatpak's portal layer would answer that kind of desktop-integration/theme query very differently than a direct GTK call to Hyprland.

   Given this reproduces across 6.x–7.2.1 (per the AUR thread) and now two independent reports here, it looks like a real, long-standing incompatibility rather than an isolated config problem. Happy to pull a full debuginfo-backed backtrace or run other diagnostics if that would help pin the exact throw site.
3. sling86 commented on Sep 14, 2026

   

   sling86

   on Sep 14, 2026

   Last edited by sling86

   More actions

   Root cause found, with a per-app workaround that doesn't touch system libraries.

   This is not a tiling-WM problem. It's a FreeType symbol collision in the AppImage, and the trigger is a variable font.

   The mechanism

   The CrealityPrint executable statically links its own FreeType and exports its symbols from the binary:

   $ nm -D --defined-only squashfs-root/bin/CrealityPrint | grep FT_
   0000000004685270 T FT_Done_Face
   000000000468ee50 T FT_Init_FreeType
   

   The executable's symbols take precedence in the dynamic linker's global lookup scope, so the host cairo/pango/GTK stack binds FT_* to the app's bundled copy while /usr/lib/libfreetype.so.6 (2.14.3 here) keeps calling its own internals. Two FreeType versions end up sharing FT_Face objects with different struct layouts.

   That only faults on variable fonts, because they are the only ones that reach FT_Set_Var_Design_Coordinates / tt_apply_mvar. Caught in a second core dump with the split visible in one stack:

   #0  tt_apply_mvar ()                      <- resolved inside the app binary
   #1  FT_Set_Var_Design_Coordinates ()      <- from /usr/lib/libfreetype.so.6
   #2-#6  cairo
   #7-#16 pango
   #17 wxCairoContext::GetTextExtent(...)
   #18 wxGCDCImpl::DoGetTextExtent(...)
   #19 Button::messureSize()
   

   Corrupt text extents then produce ~91x gtk_widget_set_size_request: assertion 'width >= -1' failed, the app's own font check fires (add_msg_content invalid font detected gui_ok=true mono_ok=false), MainFrame construction is abandoned, the half-built Plater is destroyed, and Plater::priv::~priv() destroys a still-joinable std::thread -> terminate called without an active exception -> SIGABRT. That is the stack in this issue.

   The trigger

   /usr/share/fonts/Adwaita/AdwaitaSans-Regular.ttf, axes ['opsz', 'wght']. The original core contains the string wght=400,opsz=15.4006, matching those axes.

   Bisected with FONTCONFIG_FILE on Arch, 7.2.1.5476 AppImage, Hyprland:

   fontconfig	result
   unmodified	crashed 6/6
   reject /usr/share/fonts/Adwaita/*	survived 4/4
   reject SegUIVar.ttf only	still crashed
   reject Sitka* only	still crashed

   Ruled out: memory pressure, GDK_BACKEND=x11 and =wayland, GDK_SCALE, fractional display scaling, WEBKIT_DISABLE_COMPOSITING_MODE, WEBKIT_DISABLE_DMABUF_RENDERER, LIBGL_ALWAYS_SOFTWARE. All still crash.

   This explains the other reports

   • 7.0.0 AppImage not working on Arch Linux + Gnome 49 #522 (closed) worked around it by downgrading freetype2 to 2.13.0. Same root cause — an older host FreeType happens to be layout-compatible with the bundled one.
   • Flatpak works because the GNOME runtime supplies its own matched FreeType and font set inside the sandbox, not because of portals or theming.
   • The sway / qtile / Hyprland correlation is coincidental. adwaita-fonts is a hard dependency of gtk3 -> at-spi2-core -> gsettings-desktop-schemas, so it is present on those systems; what matters is whether a variable font gets selected for UI text, not the compositor.
   • The gsettings set org.gnome.desktop.interface font-name 'Noto Sans 11' suggestion in the thread works for the same reason — Noto Sans is static.

   Workaround that doesn't downgrade anything

   Launch with a fontconfig that hides the variable font from this process only:

   <?xml version="1.0"?>
   <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
   <fontconfig>
     <include ignore_missing="yes">/etc/fonts/fonts.conf</include>
     <selectfont><rejectfont>
       <glob>/usr/share/fonts/Adwaita/*</glob>
     </rejectfont></selectfont>
   </fontconfig>

   Then FONTCONFIG_FILE=/path/to/that.conf ./CrealityPrint-V7.2.1.5476-x86_64-Release.AppImage. Verified across repeated launches; the app reaches the main window and stays up.

   Suggested fixes

   1. Stop exporting the bundled FreeType symbols. Link it with a version script or -fvisibility=hidden, or drop the static FreeType and use the host's. This is the actual bug and it will keep biting on any distro whose FreeType has moved on.
   2. Separately, harden Plater::priv::~priv(). A joinable std::thread member destroyed without join/detach turns any failure during MainFrame construction into an unconditional abort with no diagnostic. Joining or detaching it would have surfaced a readable font error instead of SIGABRT, in this bug and in every future one that trips the same path.

   Happy to supply the full core dumps or run further diagnostics.