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

Slic3r freezes during the brim calculation #4654

Closed
hariseldon78 opened this issue Dec 28, 2018 · 9 comments
Closed

Slic3r freezes during the brim calculation #4654

hariseldon78 opened this issue Dec 28, 2018 · 9 comments
Labels
Crash Bug :-( Fixed with PR available to merge There is an update to address this issue in an open pull request. Fixed Verified bug This issue has been reproduced by a developer Workaround
Milestone

Comments

@hariseldon78
Copy link

Describe the bug
Slic3r freezes during the brim calculation of this model:
pulley.zip
, and the interface become irresponsive, even after cancelling the calculation. It happens with the object non rotated or rotated 90 on x axis. It slices fine without brim.

To Reproduce
Steps to reproduce the behavior:

  1. add the attached model
  2. configure a brim (2 mm in my configuration)
  3. click on Preview
  4. after a couple of seconds the slic3r crashes and the ui become irresponsive

3D Model and Slic3r Configuration Export
config.zip
pulley.zip

Expected behavior
correct slicing, the model is manifold and I didn't find any problem with it.

Desktop (please complete the following information):

@lordofhyphens lordofhyphens added Verified bug This issue has been reproduced by a developer Crash Bug :-( labels Dec 31, 2018
@lordofhyphens
Copy link
Member

Traceback:

#0  0x00007f947a8fff11 in Slic3r::_align_to_grid (spacing=0, coord=-499899) at src/libslic3r/Point.cpp:324
324	    return aligned;
[Current thread is 1 (Thread 0x7f944f7fe700 (LWP 14111))]
(gdb) back
#0  0x00007f947a8fff11 in Slic3r::_align_to_grid (spacing=0, coord=-499899) at src/libslic3r/Point.cpp:324
#1  Slic3r::Point::align_to_grid (this=this@entry=0x7f944f7fd550, spacing=..., base=...) at src/libslic3r/Point.cpp:330
#2  0x00007f947a9206d0 in Slic3r::FillRectilinear::_fill_single_direction (this=0x7f93b3aa8b90, expolygon=..., direction=..., x_shift=<optimized out>, out=0x7f944f7fd770) at src/libslic3r/Fill/../Point.hpp:36
#3  0x00007f947a92294b in Slic3r::FillRectilinear::_fill_surface_single (this=this@entry=0x7f93b3aa8b90, thickness_layers=<optimized out>, direction=..., expolygon=..., out=out@entry=0x7f944f7fd770)
    at /usr/include/c++/8/bits/stl_iterator.h:804
#4  0x00007f947a958b49 in Slic3r::Fill::fill_surface (this=0x7f93b3aa8b90, surface=...) at /usr/include/c++/8/bits/stl_vector.h:930
#5  0x00007f947a90875a in Slic3r::Print::_make_brim (this=0x561d902773e0) at /usr/include/c++/8/bits/stl_uninitialized.h:115
#6  0x00007f947a602e1f in XS_Slic3r__Print__make_brim (my_perl=<optimized out>, cv=<optimized out>) at /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t "../xsp/typemap.xspt"  "../xsp/Print.xsp":1234
#7  0x0000561d8c479d11 in Perl_pp_entersub ()
#8  0x0000561d8c470026 in Perl_runops_standard ()
#9  0x0000561d8c3e3f02 in Perl_call_sv ()
#10 0x00007f947b0e852e in S_jmpenv_run (my_perl=my_perl@entry=0x561d915ed360, action=action@entry=0, thread=thread@entry=0x561d90d57c50, len_p=len_p@entry=0x7f944f7fdebc, 
    exit_app_p=exit_app_p@entry=0x7f944f7fdeb4, exit_code_p=exit_code_p@entry=0x7f944f7fdeb8) at threads.xs:508
#11 0x00007f947b0eaf7d in S_ithread_run (arg=0x561d90d57c50) at threads.xs:602
#12 0x00007f947b2f8fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#13 0x00007f947b22988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Interesting, the coordinate is strongly negative.

@lordofhyphens
Copy link
Member

The negative coordinate isn't anything interesting. However, the spacing is, in this case, 0. I'm not sure why currently.

@hariseldon78
Copy link
Author

the stl is generated in freecad, i can post the project file tomorrow if it can help debugging

@lordofhyphens
Copy link
Member

@hariseldon78 no, the model as posted is enough to trigger the crash and I found at least one of the pieces.

So it looks like the trigger was the 125% first layer setting. That, plus the brim connections, is causing the brim code to bug out and try to produce a 0 spacing path (which is normally illegal). We have some asserts in the code but they aren't triggering in this situation (and I'm not sure why right now).

@lordofhyphens
Copy link
Member

@hariseldon78 With that model, a current workaround is to either set the brim connections to 0mm or set the first layer width to 200% (the default).

There's something going on with I think the flow code (remember, % width is relative to the layer height) that when Slic3r is trying to place that brim connector, the spacing is 0.

The spacing value (which is the width-to-width) is being set incorrectly with that brim connection with and the math happens to work out that it comes out to be 0 on that model and a line width of ~0.5mm.

@lordofhyphens
Copy link
Member

Well, I know why it's tripping the assert: the build didn't have SLIC3R_DEBUG set, which automatically turns off asserts.

lordofhyphens added a commit that referenced this issue Dec 31, 2018
…ed a regression test to ensure that the spacing can't be 0 with otherwise valid inputs.
@lordofhyphens
Copy link
Member

@hariseldon78 in about 30-40 minutes you can check https://dl.slic3r.org/dev/linux/branches/ for a build of PR4662 that should sort out the crash. Please let me know if it fixes it for you (it does when I was testing it with your provided config and model).

What was happening is that even with the 0.5 fudge factor, with a 125% and 0.4 first layer height it happens to not reach the threshold for the math and gets rounded down to 0; 0 spacing breaks almost all of the assumptions in the slicer. I've patched a backup approach into the flow calculation that tries to choose an "okay" flow calculation in these situations (which I'm fairly certain only occur with brims).

@lordofhyphens lordofhyphens added the Fixed with PR available to merge There is an update to address this issue in an open pull request. label Dec 31, 2018
@lordofhyphens lordofhyphens added this to the 1.3.1 milestone Dec 31, 2018
@hariseldon78
Copy link
Author

I confirm that this build slices correctly with 2mm brim, 1mm brim connections, 125% first layer thickness and 0.4mm first layer height. Thanks for the very quick fix, and happy new year!

lordofhyphens added a commit that referenced this issue Dec 31, 2018
…ed a regression test to ensure that the spacing can't be 0 with otherwise valid inputs.
supermerill pushed a commit that referenced this issue Sep 6, 2021
Fixing model import of models with nearly degenerate triangles, which
degenerate after transformation (translation or rotation).

There was certainly a bug in PrusaSlicer, however this bug was triggered
mostly by the ASCII STL files generated by OpenSCAD, likely due to insufficient
number of decimal digits when saving an ASCII STL, see
[openscad/openscad] STL export should contain single precision floats (#2651)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Crash Bug :-( Fixed with PR available to merge There is an update to address this issue in an open pull request. Fixed Verified bug This issue has been reproduced by a developer Workaround
Projects
None yet
Development

No branches or pull requests

2 participants