QIDI Studio Segfaults on Linux Once You Add a Printer — The Real Fix

QIDI Studio (the slicer for QiDi 3D printers) runs fine on Linux right up until you add a physical printer as a network device. Save that config, and the app crashes — then segfaults on every subsequent launch, before you even get to the main window. It looks like something broke in your setup. It didn't — this is a known WebKitGTK conflict QIDITECH documents in their own release notes, and the fix is two settings in the printer profile, not a reinstall.

The symptom

Add a printer through QIDI Studio's Physical Printer dialog — hostname/IP, printer preset, API key — click Test (works fine), then OK to save. The app crashes almost immediately. Relaunch it, and it crashes again within a second or two, every time, before the main window even finishes loading. Right before the crash, the terminal shows a burst of GTK warnings:

Gtk-CRITICAL **: gtk_window_resize: assertion 'width > 0' failed

followed immediately by a segfault.

Confirming it with dmesg, not guessing

Worth pinning down the actual crashing library before assuming it's your printer config, your GPU drivers, or your display setup. dmesg names it precisely:

segfault at 48 ip 00007f...cec04e sp 00007f...c10 error 4 in libwebkit2gtk-4.1.so.0.21.9[...]

A null-pointer dereference inside WebKitGTK — QIDI Studio embeds a WebKit view for its device-status/login panel, and that's what's actually crashing, not the slicer core. To confirm it's specifically the saved-printer reconnect flow and not something else, temporarily move the saved profile out of the way (~/.config/QIDIStudio/user/default/physical_printer/<name>.json) and relaunch — the app runs fine with no printer configured, and crashes instantly the moment that file is put back. That isolates the trigger precisely: the panel shown when reconnecting to a saved device.

Why it happens

Check QIDITECH's own GitHub release notes and it's right there, undisguised, in a section literally titled "Note for Linux Users":

Due to a conflict with WebKit in Linux, the software may crash. It is recommended to manually add the port number 7125 when adding a device... not checking "Expert Mode" when adding a device and displaying the Device Control Page can avoid the software crash issue caused by the WebKit bug.

This is a real, acknowledged, still-open issue as of the latest release checked — not something patched out yet, and not something specific to any one distro or desktop environment.

The fix

Two settings in the saved printer profile:

1. Turn off "Expert Mode" when adding the device. This is what actually shows the WebKit-based Device Control Page that crashes — skipping it avoids the whole code path.
2. Set the print host port explicitly to 7125 — Moonraker's real API port, rather than leaving it blank and relying on whatever the bare hostname/IP falls back to.

If the crash already happened and the app won't get far enough to let you uncheck the box in the UI, edit the saved profile JSON directly:

~/.config/QIDIStudio/user/default/physical_printer/<printer-name>.json

{
    "expert_mode": "0",
    "printhost_port": "7125",
    ...
}

Save it, relaunch. The reconnect happens the same way, but the panel that was crashing never gets shown — the app comes up stable instead of segfaulting.

Worth checking before you reinstall or downgrade

It's tempting to assume a fresh install or a different package source will fix a crash like this — it won't, since the bug lives in how the Device Control Page renders, not in the package itself. Check the project's GitHub releases page for the specific "Note for Linux Users" section before spending time on a reinstall; if it's still listed there, the two-setting fix above is the actual answer regardless of which build you're running.