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

Cura constantly crashing with slice automatically #19904

Open
joezappie opened this issue Nov 13, 2024 · 7 comments
Open

Cura constantly crashing with slice automatically #19904

joezappie opened this issue Nov 13, 2024 · 7 comments
Labels
Status: On Backlog The issue / feature has been reproduced and is deemed important enough to be fixed. Type: Bug The code does not produce the intended behavior. Type: Improvement Improvement to existing functionality.

Comments

@joezappie
Copy link

joezappie commented Nov 13, 2024

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:

  1. Enable Slice Automatically
  2. Switch to preview mode
  3. Add a filament change post processing script
  4. Type 2-3 numbers into the "layers box"

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

@joezappie joezappie added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Nov 13, 2024
@GregValiant GregValiant added Type: Improvement Improvement to existing functionality. Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Nov 13, 2024
@GregValiant
Copy link
Collaborator

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.

@joezappie
Copy link
Author

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.

@GregValiant
Copy link
Collaborator

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.

@HellAholic
Copy link
Contributor

@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.

@GregValiant
Copy link
Collaborator

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.

@HellAholic
Copy link
Contributor

HellAholic commented Nov 14, 2024

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

@joezappie
Copy link
Author

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.

@HellAholic HellAholic added Status: On Backlog The issue / feature has been reproduced and is deemed important enough to be fixed. and removed Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. labels Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: On Backlog The issue / feature has been reproduced and is deemed important enough to be fixed. Type: Bug The code does not produce the intended behavior. Type: Improvement Improvement to existing functionality.
Projects
None yet
Development

No branches or pull requests

3 participants