Order-dependent crash when slicing two objects if one object is exactly 5mm tall

[seancmonahan]

What happened?

With two Shape-Box objects where one of them is scaled to 5mm tall, SuperSlicer crashes when slicing depending on the slicing order of the objects. If the 5mm box comes before the taller one, it crashes. If they are re-ordered so the taller one is first, it does not crash.

Slicing either object separately works as expected.

This is with the system presets "0.20mm NORMAL", filament "Generic PLA", and printer "Creality Ender-3 V2".

Using the command-line --loglevel 5, the last message before the crash is Exported layer 24 print_z 5

It also crashes with layer height=0.16, which doesn't exactly divide 5.0 mm. In this case the final message is Exported layer 30 print_z 5

The crash is present in both release 2.5.59.11 and in the latest build, SuperSlicer_2.5.60.0_2024-06-05.

Project file & How to reproduce

1. Right-click bed, "Add Shape"->Box
2. Scale this "Shape-Box" to 5 mm tall
3. Right-click bed, "Add Shape"->Box
4. Slice (crashes)

Notably, re-ordering the two objects before slicing leads to it not crashing.

Bug is still present in the latest GitHub Actions build SuperSlicer_2.5.60.0_2024-06-05 (SuperSlicer_ubu64_c493c0107b1154c2e4aa34e91a09cec6.AppImage)

two-boxes-one-5mm-tall-crash.zip

Version

2.5.59.11 (also present in SuperSlicer_2.5.60.0_2024-06-05)

Operating system

AppImage (SuperSlicer-ubuntu_20.04-2.5.59.11_1064f8b97280bccbd2d0d6a173f1e0d3.AppImage)

Printer model

Creality Ender-3 V2

[seancmonahan]

Coredump shows segfault in Slic3r::GCode::process_layer(...)

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000057435f3602d5 in Slic3r::GCode::process_layer(Slic3r::Print const&, Slic3r::Print::StatusMonitor&, std::vector<Slic3r::GCode::LayerToPrint, std::allocator<Slic3r::GCode::LayerToPrint> > const&, Slic3r::LayerTools const&, bool, std::vector<Slic3r::PrintInstance const*, std::allocator<Slic3r::PrintInstance const*> > const*, unsigned long) ()
[Current thread is 1 (Thread 0x72642aa006c0 (LWP 144942))]

Full backtrace: segfault-backtrace.txt

[supermerill]

seems like the same crash as #4309 you pinpoint the problem well: if the first object is not the tallest, then it will crash. fixed in next nightly & release.