← Back to Wiki
3D Printing / Linux

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 it segfaults on every launch after that, before you reach the main window. It looks like something broke in your setup. It did not. 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.

Share on X

The symptom

Add a printer through QIDI Studio's Physical Printer dialog. Hostname or IP, printer preset, API key. Click Test, which 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 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

Pin down the actual crashing library before you blame 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[...]

That is a null-pointer dereference inside WebKitGTK. QIDI Studio embeds a WebKit view for its device-status and login panel, and that is what crashes, not the slicer core. To confirm it is the saved-printer reconnect flow and nothing else, move the saved profile out of the way and relaunch. The file is ~/.config/QIDIStudio/user/default/physical_printer/<name>.json. The app runs fine with no printer configured, and crashes instantly the moment that file goes back. That isolates the trigger. It is the panel shown when reconnecting to a saved device.

BE WARNED: the usual WebKitGTK and AMD-Wayland crash workarounds do not fix this one. WEBKIT_DISABLE_DMABUF_RENDERER=1 and WEBKIT_DISABLE_COMPOSITING_MODE=1 are the standard environment-variable fixes for WebKitGTK crashes on AMD GPUs under Wayland. Try them first for any WebKitGTK segfault. Neither changes anything here. This is not a GPU-rendering-path bug. It is specific to the device-login panel.

Why it happens

Check QIDITECH's own GitHub release notes and it is right there, undisguised, in a section literally titled "Note for Linux Users". This text is from the v2.07.02.60 notes, dated 2026-08-06:

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.

So it was still open in v2.07.02.60, acknowledged by the vendor and not patched out. It is not specific to any one distro or desktop environment either. Check the notes on whatever release you are running before you assume it has since been fixed.

Check your installed version, not just the latest one. The crash here happened on v2.07.02.10 from the AUR, roughly a month behind v2.07.02.60 at the time. A packaged build lagging upstream is normal, and it means the release notes describing your symptom may sit several versions ahead of what you actually have installed.

The fix

Two settings in the saved printer profile:

  1. Turn off "Expert Mode" when adding the device. That is what shows the WebKit-based Device Control Page that crashes. Skip it and you avoid the whole code path.
  2. Set the print host port explicitly to 7125, Moonraker's real API port. Leave it blank and it falls back to whatever the bare hostname or IP resolves to.

If the crash already happened and the app will not 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 and relaunch. The reconnect happens the same way. The panel that was crashing never gets shown, and the app comes up stable instead of segfaulting.

Worth checking before you reinstall or downgrade

It is tempting to assume a fresh install or a different package source fixes a crash like this. It does not. The bug lives in how the Device Control Page renders, not in the package. Check the project's GitHub releases page for that "Note for Linux Users" section before you spend time on a reinstall. If it is still listed there, the two-setting fix above is the answer whatever build you run.