Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account
Jump to bottom

Prusa slicer segfaults when using the --split option from the command line #5979

Closed
NuclearLighthouseStudios opened this issue Feb 6, 2021 · 4 comments
Closed

Prusa slicer segfaults when using the --split option from the command line #5979

NuclearLighthouseStudios opened this issue Feb 6, 2021 · 4 comments

Comments

@NuclearLighthouseStudios
Copy link

Version

2.3.0, though this same bug has existed in previous versions

Operating system type + version

Arch Linux

3D printer brand / version + firmware version (if known)

Prusa i3MK3S

Behavior

When slicing an object from the command line using the --split option will result in a segmentation fault.
This seems to happen regardless of the mesh, wether is actually has multiple parts that can be split, and the slicing settings.

Steps needed to reproduce the problem

Run prusa-slicer on any stl or 3mf using the --split option, for example:
prusa-slicer -s --split boxes.3mf

Expected Results

The mesh gets split into multiple parts and sliced.

Actual Results

Prusa-slicer segfaults.

Example

$ prusa-slicer -s boxes.3mf
10 => Processing triangulated mesh
20 => Generating perimeters
70 => Infilling layers
30 => Preparing infill
88 => Generating skirt
90 => Exporting G-code to boxes_0.2mm_PLA_MK3S_{print_time}.gcode
Slicing result exported to boxes_0.2mm_PLA_MK3S_5h35m.gcode
$ prusa-slicer -s --split boxes.3mf
Segmentation fault (core dumped)
$

Example files

Both of these files reproduce the error when prusa-slicer is run on them using the --split option.
files.zip
combolek added a commit to combolek/PrusaSlicer that referenced this issue Feb 8, 2021
@combolek
Fixes issue prusa3d#5979 - NULL pointer crash in ModelObject::split()
3803fa2 
ModelObject::split() expects a non-NULL new_objects vector where it adds pointers to the new models resulting from the split. But in the CLI case the caller does not care about this and passes NULL which causes a crash. To fix the crash we could pass a dummy vector but it turns out that we actually have a use for the results because we should assign a unique name to each new model the same way as the GUI does. These names show up as comments in the gcode so this change makes the gcode produced by the GUI and the CLI more similar and diffable.
@combolek
Copy link
Contributor

@NuclearLighthouseStudios Can you try PR #5991 ?

lukasmatena pushed a commit that referenced this issue Feb 8, 2021
@combolek @lukasmatena
Fixes issue #5979 - NULL pointer crash in ModelObject::split()
b85480c 
ModelObject::split() expects a non-NULL new_objects vector where it adds pointers to the new models resulting from the split. But in the CLI case the caller does not care about this and passes NULL which causes a crash. To fix the crash we could pass a dummy vector but it turns out that we actually have a use for the results because we should assign a unique name to each new model the same way as the GUI does. These names show up as comments in the gcode so this change makes the gcode produced by the GUI and the CLI more similar and diffable.
@NuclearLighthouseStudios
Copy link
Author

Confirmed working!

@combolek
Copy link
Contributor

Cool, thanks for testing. I think Lukas is working on a better fix.

lukasmatena pushed a commit that referenced this issue Feb 10, 2021
@combolek @lukasmatena
Fixes issue #5979 - NULL pointer crash in ModelObject::split()
22b2ccc 
ModelObject::split() expects a non-NULL new_objects vector where it adds pointers to the new models resulting from the split.
But in the CLI case the caller does not care about this and passes NULL which causes a crash. To fix the crash we could pass
a dummy vector but it turns out that we actually have a use for the results because we should assign a unique name to each
new model the same way as the GUI does. These names show up as comments in the gcode so this change makes the gcode produced
by the GUI and the CLI more similar and diffable.

@lukasmatena has amended the original commit by @combolek (pull request #5991) in order to avoid code duplication
@lukasmatena
Copy link
Collaborator

Should be fixed with 22b2ccc for 2.3.1. Thanks @combolek for the fix provided in #5991.
Closing.

@bubnikv bubnikv mentioned this issue Aug 6, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@combolek @lukasmatena