-
Notifications
You must be signed in to change notification settings - Fork 10
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 5.7 beta crashes when trying to upload a file via the plugin #53
Comments
Thanks for the report - unfortunately I don't see an error in the logs related to the Duet-RRF plugin. I see successfully rendered files and thumbnails from the plugin, e.g., from I see one attempt using the "Print on" button around timestamp Can you delete (empty) your log file, and try with a clean Cura start-up -- without any other plugins loaded. Can you replicate your issue using the same Cura config and profiles but on a different operating system / computer? POP!_OS sounds like Raspberry Pi - and there might be a Cura or plugin incompatibility in this lesser known OS - but I'm just speculating at this point. |
Hi,
POP!_OS is a Ubuntu derivative, and I am running the standard AppImage. I did save the Gcode file to print after Cura repeatedly crashed. I will provide a clean log file in a short while.
…-------- Ursprüngliche Nachricht --------
Am 31.03.24 19:09 um Thomas Kriechbaumer schrieb :
Thanks for the report - unfortunately I don't see an error in the logs related to the Duet-RRF plugin.
I see successfully rendered files and thumbnails from the plugin, e.g., from green.gcode, but this seems like you used the "Save to file" button.
I see one attempt using the "Print on" button around timestamp 2024-03-30 19:19:28, but the logs just end and then 70sec later Cura seems to start-up again -- but there are no error logs or other indications what when wrong. I'm afraid we would need a Cura/UltiMaker dev input for that.
Can you delete (empty) your log file, and try with a clean Cura start-up -- without any other plugins loaded.
Then mark the time when you were able to trigger a crash (i.e., clicked the "print on" button), so we can compare it against the timestamps in the log file.
Can you replicate your issue using the same Cura config and profiles but on a different operating system / computer? POP!_OS sounds like Raspberry Pi - and there might be a Cura or plugin incompatibility in this lesser known OS - but I'm just speculating at this point.
—
Reply to this email directly, [view it on GitHub](#53 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAJMOI2EVDA6ZYC2EPTZCOTY3A7N7AVCNFSM6AAAAABFPXXHYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYHAZDMMBUGA).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I can reproduce and confirm this issue on Ultimaker Cura 5.7.1.
|
I can confirm this still happens with 5.7.1 for me. I haven't been at my printer in a long while, so I still owe you a set of log files. |
Confirming the issue on 5.7.1 as well. As a workaround, the crash doesn't happen if I do "Save to Disk" before. |
Please try installing from source using the I don't know why or where exactly this is crashing, as a |
I can confim that both the workaround in #53 (comment) (save to disk before upload/print/simulate) and disabling thumbnail generation work.I did poke around in the cura directory and actually found some more info about the crash in $HOME/.local/share/cura/stderr.log. I have attached it here. |
Added a bit more log output and am now pretty sure the thumbnail generation crashes inside from cura.log:
|
Taking another look at the stderr.log
I disabled the Octoprint plugin to see if that helps; only marginally since the crash traceback then starts in RemovableDriveOutputDevice, which cannot be disabled via UI. I will look into modifying the AppImage to get that plugin disabled for testing. |
These are mostly background threads - and I think not relevant in this case. The important thread is this one:
And as you pointed out, it crashes in the Snapshot.snapshot function, which is called by the plugin code: Cura-DuetRRFPlugin/thumbnails.py Line 73 in fafa99f
Looks like a rather straight forward function call to me - so I suspect an issue with Cura or underlying libraries. I suggest opening a new issue with Cura - there have been a few similar ones in the past: https://github.com/search?q=repo%3AUltimaker%2FCura+snapshot.snapshot&type=issues |
I also pushed a new commit with a suggested fix from one of these issues: Please test the latest version from the branch, or make the changes in the mentioned 3 lines of code. |
Updated next branch, the crash still happens, _call_on_qt_thread_wrapper now part of the trace. The workaround with saving to disk first still applies.
|
Looking at Snapshot.py and RenderBatch.py between 5.6 and 5.7, there haven't been many changes: Snapshot.py got a slight refactor and RenderBatch.py is unchanged. So it's most likely underlying Qt or GL changes that cause the issue here. I will take a break and investigate a bit further later. |
@oliof thanks - I've pushed another commit, moving the |
no meaningful improvement. I have a trivial STL that doesn't always crash (basically a washer), but even a simple plate with four holes makes things go sideways
|
I've now published v1.2.11 which includes an option to enable/disable thumbnail creation and also to select which sizes to generate. If anyone still has issues with crashes like discussed here, please directly open a new bug report with Cura: |
Describe the bug
Uploading files via the plugin causes to crash
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Sending files to RRF should work
Version Information
Cura Log
cura.log
The text was updated successfully, but these errors were encountered: