Open joezappie opened 4 days ago
Thanks for the report. There was just a discussion on the UM Forum about this behavior. I would think that an "anti-bounce" wait of 1/2 second would be about right.
This is halfway between a bug and an Improvement request so I'm going to add the "Improvement" label to this.
Someone from the Cura team will take a look.
Thanks for the reply - some updated info:
I've been playing around with this a bit more, and I do find that I can also get Cura to crash just by slowly toggling the enable
checkbox under filament change, which kind of leads me to believe maybe its not caused by what I suggested above as that should only trigger the automatic slicing once. But maybe internally something with that single change is still causing Cura to reslice several times, I dont know.
That said, I've sat here toggling enable once a second about 30 times while in the "Prepare" tab and cannot get Cura to crash. Once I switch back to preview, it crashes within a few clicks, almost always on the first however.
Heres an updated video showing cura crashes after slowly toggling the enabled checkbox: https://www.youtube.com/watch?v=aZ4x3V5gWQk
I have no issues with automatic slicing turned on and dragging the part around causing Cura to reslice. It only seems to be in the post processing scripts that its crashing.
I still think a debounce on reslicing would be a good addition though, despite maybe not a solution to my current issue.
Someone from the Cura team will take a look (@HellAholic might find this interesting?). The team is busy getting ready for the release of 5.9.0 stable so it may be a bit before something can be done about this.
@GregValiant I took a quick look and it doesn't seem to be directly related to the engine itself. I'll take another look over the weekend but my suspicion is the post processing script not handling the change.
To check, you can remove the post processing, and follow the same steps as described, but instead of value in post processing, change infill value for the model. This is just guesstimation and suspicions at this point, I'll let you know if I find anything.
My thought was that there isn't anything within a post-processor that would control how Cura picks up and emits a change to a setting. Could it be a "QML" thing? It would be impossible to know when the user has finished typing but a short "don't start/restart auto-slicing just yet" dwell might mitigate this behavior.
I've spent the last 20 minutes playing with this trying to force the crash. It seems to be very intermittent. I'm unable to force the crash using @joezappie's method. I tried in 5.8.0, 5.8.1, and 5.9.0beta.2. 5.9.0 crashed once, but it doesn't seem to want to duplicate.
The crashes it produces are hard application crash that doesn't get logged in configurations which means the entire app just closes from the system. I managed to reproduce on my device but took a couple of tries, after that it kept happening, but my response was mainly guesstimate. The thing is that the Post processing happens after gcode is generated, and it happens in frontend, so that's why I was suspicious of the script. I'll poke around a bit more later, but let me know if you found anything in the meantime.
Update: As far as I could find (disabling functions/operations/adding delays/...), the issue is caused by an "access violation" most likely for the global container stack. I tried adding a delay of 2 seconds before triggering the re-slice but that also didn't solve the crash (at least on my device). I'll add a ticket on the backlog: CURA-12309
Thanks for taking a look at this and that's great to hear its reproduceable!
Just as an update, I've been paying attention to the crashes more closely now and I was wrong saying it never happens on the "prepare" tab. I have never seen it crash from changing any settings such as infill or moving objects around the scene.
Let me know if there's any other info that would be helpful that I can provide or if you want me to try out any changes.
Cura Version
5.8.1
Operating System
Windows 11
Printer
S1 Pro with Sonic pad
Reproduction steps
I've been having regular cura crashes for the past several months. Every update I hope that some bug was fixed that stops it but unfortunately it hasn't.
I believe this has to do with "Slice Automatically" being enabled and making a change that causes Cura to reslice many times in a short period. I believe it also has to do with being in preview mode.
I can guarantee Cura to crash by:
It seems that input boxes trigger on input, not on change, so typing fast into these boxes causes Cura to reslice several times in a short time, probably overlapping.
Cura just closes. I don't get any crash report. Looking in the
cura.log
in%appdata%
I don't see much in terms of why it closed.This happens with any model, as simple as a basic cube so I have not included a project file. I also have slowly removed every extension I use except moonraker, to see if an extension was causing the crash. It only happens when slice automatically is enabled. I never get a crash when manually slicing.
Demonstration
Heres a youtube video showing how easy it is for me to get Cura to crash. After typing 104 into the input field, I don't click on anything else. It seems the slice finishes, but everything hangs, I get the spinning cursor icon, then cura closes. https://www.youtube.com/watch?v=EUsGKntIf3g
Proposed solution
Debounce slicing. I think slice automatically should delay ~500 ms. If another slice request is made within that time, it defers it again. This would reduce the number of times Cura reslices, whether that's from typing in an input box, or an extension causing a reslice after it just happened. Maybe Cura already does this, but to me it doesn't seem like that's happening.
Actual results
Cura crashes when making changes
Expected results
Cura shouldnt crash when making changes
Add your .zip and screenshots here ⬇️
I deleted my cura.log, reopened Cura, did the above steps and here's the log file after it crashed: https://pastebin.com/vF8EDwWs