Segmentation fault in Slic3r::DynamicPrintConfig::normalize_fdm

[RyanHeule]

Description of the bug

I attempted to use the command line interface to slice an STL file and export the resulting G-code, but received a segmentation fault. Even with --loglevel 5, I receive no output except the segmentation fault message.

I was able to debug this some. The stack trace is:

#0  0x0000000000518857 in Slic3r::DynamicPrintConfig::normalize_fdm (this=0x7ffc56733540) at /usr/src/debug/prusa-slicer-2.8.0-3.fc40.x86_64/src/libslic3r/PrintConfig.cpp:4956
#1  0x0000000000708635 in Slic3r::CLI::run (this=this@entry=0x7ffc56738bc0, argc=7, argv=0x7ffc56738e28) at /usr/src/debug/prusa-slicer-2.8.0-3.fc40.x86_64/src/PrusaSlicer.cpp:165
#2  0x00000000006811e0 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/prusa-slicer-2.8.0-3.fc40.x86_64/src/PrusaSlicer.cpp:1155

The code near the segmentation fault is :

    if (this->has("wipe_tower_extruder")) {
        // If invalid, replace with 0.
        int extruder = this->opt<ConfigOptionInt>("wipe_tower_extruder")->value;
        int num_extruders = this->opt<ConfigOptionFloats>("nozzle_diameter")->size();
        if (extruder < 0 || extruder > num_extruders)
            this->option("wipe_tower_extruder")->setInt(0);
    }

The actual segmentation fault is on this line:
int num_extruders = this->opt<ConfigOptionFloats>("nozzle_diameter")->size();

My real configuration files and STL are not included, I was able to reproduce with a very minimal example (a 1-line configuration file and no STL -- just loading the configuration file reproduces the segmentation fault with the same stack trace).

The root cause appears to be using --load= with any configuration file that contains a wipe_tower_extruder line without a nozzle_diameter line.

In my real use case, I am using separate printer, filament, and print configuration files (just like how the GUI saves them) and --load for each one. The wipe_tower_extruder option is in my print configuration, whereas the ````nozzle_diameteroption is in my printer configuration (again, exactly how the GUI exports these files). It does not seem to matter what order I put the--load``` options.

As a workaround, I can delete the wipe_tower_extruder = 0 line from my configuration (since I'm not using a wipe tower anyway) and it works as expected.

Project file & How to reproduce

$ echo 'wipe_tower_extruder = 0' > test.ini
$ /usr/bin/prusa-slicer --load=test.ini
Segmentation fault (core dumped)

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.8.0

Operating system

Fedora 40

Printer model

Ender 3 Pro

[RyanHeule]

It seems to me that Slic3r::DynamicPrintConfig::normalize_fdm, at least when processing files from --load, must only consider options in a single configuration file.

I have not tried to run a newer version, however the same code path still appears to be present in the current master branch:

PrusaSlicer/src/libslic3r/PrintConfig.cpp

Line 5136 in 5c7888b

int num_extruders = this->opt<ConfigOptionFloats>("nozzle_diameter")->size();

Looking at the history, this appears to have been introduced by 6c00a9d while attempting to fix another crash.

I am not familiar with this code base, but I may attempt a pull request with a proposed fix. However I see a lot of potential for accidental regression of the original issue, only partially fixing the issue, or causing new issues. For example, the most obvious solution would be to change the first line to:

if (this->has("wipe_tower_extruder") && this->has("nozzle_diameter")) {

That would fix my issue, but I think it could partially reopen the original issue around invalid wipe_tower_extruder values.

I think a full fix will need to consider alternate ways to validate wipe_tower_extruder, or consider the final / fully loaded configuration instead of each --load file at a time.

[RyanHeule]

It seems someone else has run into this too: https://forum.prusa3d.com/forum/prusaslicer/seg-fault-launching-prusaslicer-from-the-command-line/