Fix: Bambu/Orca Slicer Not Starting After Niri Update

Encountering issues with your 3D printing slicer software after a system update can be frustrating. This article addresses the problem of Bambu-Slicer and Orca-Slicer failing to start under Niri, a Wayland compositor, following a system update. We'll delve into the error messages, troubleshooting steps, and potential solutions to get your slicer software up and running again. If you've recently updated your system and found that your favorite slicer is no longer cooperating, you're in the right place. Let's dive in and explore how to resolve this issue.

Understanding the Problem: Startup Failure in Niri

After a system update, users have reported that Bambu-Slicer and Orca-Slicer fail to launch under Niri. The applications terminate with an error message, indicating a SIGTRAP signal, which is a form of breakpoint or trap signal. This type of error often points to an issue within the application's interaction with the system libraries or the graphical environment. To grasp the situation fully, let's break down the error messages and system information provided.

Analyzing the Error Messages

When attempting to start Orca-Slicer, the application terminates, producing an output that includes warnings related to gdb (GNU Debugger) and critical errors from GLib-GObject. The gdb output highlights potential issues with auto-loading Python scripts associated with GLib, a core library for many Linux applications. These warnings suggest that there might be a mismatch or conflict in library versions or configurations. However, the more critical error is the GLib-GObject-CRITICAL **: 22:27:09.753: invalid (NULL) pointer instance. This error indicates that the application is trying to access a memory location that is a null pointer, which leads to a crash. This is often a sign of a deeper issue, such as a problem with how the application is initializing or handling objects.

The backtrace from gdb provides further insight, showing the call stack leading to the crash. The issue seems to originate from within the g_logv function in libglib-2.0.so.0, which is part of the GLib library. The call stack traces back through various functions related to GTK (the graphical toolkit used by these slicers), wxWidgets (a cross-platform GUI library), and eventually to the slicer's code itself. Specifically, the crash occurs during the destruction of a wxTopLevelWindowGTK object, suggesting a problem with window management or event handling within the GUI.

System Information: Niri, NixOS, and AMD Graphics

The system information reveals a setup using Niri as the Wayland compositor on NixOS 25.11 (Xantusia). The GPU is an integrated AMD graphics processor, and the CPU is an AMD Ryzen 7 7840H. This information is crucial because it helps narrow down the potential causes of the issue. NixOS is known for its unique package management system, which uses a functional approach to ensure reproducibility. However, this can sometimes lead to conflicts or issues if dependencies are not handled correctly. The combination of Niri, NixOS, and AMD graphics suggests that the problem might be related to how the slicer applications interact with the Wayland compositor or the graphics drivers.

Troubleshooting Steps: What Has Been Tried?

To effectively address this issue, it's essential to review the troubleshooting steps already attempted. This prevents redundant efforts and helps focus on new potential solutions. The user has tried several common fixes, indicating a thorough initial investigation.

Unsuccessful Attempts

The user has explored various environment variables that can influence GTK's behavior, such as GTK_USE_PORTAL=0, GTK_CSD=0, GTK_IM_MODULE=gtk-im-context-simple GTK_A11Y=none, and GDK_BACKEND=x11. These attempts target potential issues with GTK's portal integration, client-side decorations, input method modules, accessibility settings, and the graphics backend. The fact that these measures didn't resolve the problem suggests that the issue is likely not related to these common GTK configuration problems.

Additionally, running older versions of Orca-Slicer was also unsuccessful. This eliminates the possibility of a recent bug introduced in the latest version of the slicer. It indicates that the issue is more likely related to a system-level change or a conflict with other libraries or components.

Successful Workarounds

Interestingly, the user found two workarounds that allowed the slicer to run: using `nix run nixpkgs#gamescope -- -- bash -c