Crash when Slicing Complex Objects #1313
Labels
Comments
|
Also of note: It simply hangs during slicing just a little bit more frequently than it finishes successfully. And I did eventually get the attached project file to slice. |
|
Can't makes it crash or hang, even on the 7th time. I don't know what's different between our computer to have that different behaviour. |
|
I also were able to slice it.
|
|
I was afraid it'd be Schrodinger's bug. I'm probably going to set up my own dev environment and see if I can't figure out what's up. A stack trace would be really handy right about now. |
|
Before I get too deep I'll say that my PC was overclocked and that was causing SS to crash. Reducing the clock back to stock no longer has it crashing; instead it consistently hangs now when slicing these more complex parts with the settings I attached. After building SS locally and inserting an excessive amount of logging I was able to narrow it down to the gapfill. For my test I've been slicing the AB-BN-30 duct which is a real hard nut to crack. I found that SS would hang at layer 53 every time. I narrowed this down to the MedialAxis call when generating gapfill extrusions. This particular layer has some thin walls where only two perimeters and a big fat gapfill would fit. Disabling gapfill allowed the part to slice cleanly but of course removed my gapfill. Increasing my perimeter widths also allowed the part to slice cleanly. I was running 0.38 and increased it to 0.4. I'm leaving it set to 0.4 now and have not crashed since. I've also enabled perimeter overlap which reduces the amount of gapfill. So far so good. I still don't know why it hangs on the MedialAxis call other than "my computer is wonky". In any case I'm content with my workaround. |
|
I can confirm that this also crashes SuperSlicer 2.3.56.7 making it likely related to #1389 and prusa3d#6677 I can confirm also, that: Could this be related to changes discussed in prusa3d#4422 ? Similarly to mentioned here, the crashing segment gomes down to 2 perimeters with gap fill, but i'm not sure why on the specific layer; Modified settings to Rectilinear infill and 0.4mm Default/int/ext perimeter width, SLICES OK NO CRASH: |
This was referenced Jul 13, 2021
|
I fixed an old crashy bug in the gapfill in the latest nightly. |
|
@supermerill I've compiled the nightly, issue remains under the same conditions as previously listed. As before, slicing seems to complete but crashes on parsing the gcode/rendering the sliced output. It's pretty clear that there is something going on with the gapfill + perimeter width on an AMD gpu as the trace ends with the invocation of the radeonsi_dri.so dmesg output log output (5:trace) (segfault): log output (5:trace) no crash: core dump info/backtrace: The end of strace with stack output (-vvvftk) output at the moment of the crash (entire trace at start of slicing) superslicer_strace.txt.gz |
|
Related (also AMD): As noted in many comments, setting env variable |
|
If yours is crashing during rendering then I don't think this is related to the crash that I'm experiencing. Mine happens during slicing, specifically when calculating gapfill. I can consistently get mine to work by disabling gapfill. Sometimes it'll work if I enable/disable overlapping perimeters, but it's hit or miss depending on the model. The crash happens upwards of 90% of the time. I've taken to saving the project and repeatedly opening it and hitting the slice button until it works. It's very frustrating but it doesn't happen on that many prints so I guess I'm supposed to live with it. |
|
Perhaps not exactly like yours, symptomatically, it's about the same with the same exact workarounds being applicable, definitely to do with perimeter dimension and gapfill. It crashes on your model but after slicing (no hang while slicing) when it goes to actually color the features (or whatever the preview mode is set to). Changing settings to those as you described alleviates the issue altogether but is suboptimal. Disabling OpenGL hardware rendering fixes it completely but for complex models like yours does slow it down and is a bit more cpu intensive - most smaller/simpler models do just fine. You didn't provide system information like GPU or actual debugging/trace output or more information on how you arrived at the "MedialAxis" call being the culprit so it'd be difficult to say with certainty if they are related but symptomatically and as for workaround, they are a match. Perhaps Linux does things differently than the Windows version which may be why the trigger is different, even if the end result is the same. |
|
I set LIBGL_ALWAYS_SOFTWARE=true as you suggested but that had no effect on my crash. Perhaps it doesn't do anything as I'm in Windows, not sure. I narrowed it down to MedialAxis the old fashioned way - loads of printf's until I got to the problematic call. I didn't dig further into MedialAxis itself. Again, I'm in Windows, and not really familiar with the debug tools available to me so I fell back to the old standby. |
|
@bluedragonx did you tried the latest nigthly? (available in the actions menu) |
|
I just did. It still crashes. |
Install visual studio and launch the project in debug mode, it should stop where the exception is triggered. (be sure that inside the exception windows, you have the c++ exception checked) |
|
It seems like this was fixed with e9cd154. How was this not causing that many other people issues? |
|
I take it back - it works on most files now, but there are still some things where I get consistent crashing. I'll see if I can't drill down into what. |
|
Just after launching the slicer, if you set in the task manager the thread affinity to just one core, does it continue to crash afterward? |
|
I can't reproduce the crash at all currently. Not sure why that is. I guess it's good...by accident. But this is worrying. I hate heisenbugs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When loading more complex objects SuperSlicer crashes. Sometimes, if you're patient, loading SS and slicing the same files will work but this is rare.
I first noticed this months ago when slicing Voron 2.4 parts on a much older version. I thought this was an issue with my particular slicer settings but I get the same issue when slicing with the built-in Prusa i3 profiles.
To Reproduce
Steps to reproduce the behavior:
>> Project File <<
ab-bn-30_Fan.zip
Expected behavior
More slicey, less crashy.
Desktop (please complete the following information):
Additional context
I tried using superslicer_console.exe and enabling trace logging. It's not particularly verbose but does confirm that the crash occurs while slicing.
The text was updated successfully, but these errors were encountered: