You are not logged in.
I attempted to print something today for the first time in a while and found that my installed cura crashes almost immediately after startup with the following trace output
Current thread 0x00007f8e18ede680 (most recent call first):
File "/usr/lib/python3.7/site-packages/UM/Qt/QtApplication.py", line 341 in exec_
File "/usr/lib/python3.7/site-packages/cura/CuraApplication.py", line 797 in run
File "/usr/bin/cura", line 136 in <module>
Segmentation fault (core dumped)
Installed versions
cura 4.1.0-2
qt / xfce / nouveau fully up to date.
I did verify that cura started successfully when I installed the most recent update on 15 Jun 2019 23:45:28 AEST. I'm guessing one of the qt updates since then has broken it for me.
I had a quick look through the upstream bug list but could not find anything already filed. Could somebody who uses cura please see if it starts for them to see if this is a problem specific to my machine or if it happens to everybody. If endemic, I will file a bug.
Last edited by skunktrader (2019-08-02 00:08:20)
Offline
I'm getting the same thing here, all packages up to date but using gnome and nvidia proprietary instead of xfce/nouveau.
Offline
@skunktrader
What kind of printer?
Version of python?
Last edited by Zod (2019-07-02 22:35:20)
Offline
Same here, tried downgrading to 4.0.0 but that fails as well.
Offline
The bug has been reported here
Offline
The same issue here, bug still exists. Bugreport unchanged since 03.07.
Offline
Which slicer are you using on Arch insted of Cura until the bug is fixed?
Thank you for suggestions.
Offline
so, right now, we don't have Cura on Arch Linux, right?
Offline
I have managed to make Cura to work again. As Jelly mentioned in the bugreport ( "I could reproduce the issue, but after much fiddling around this seemed to be resolved. My guess that it's related to cura's settings. But I will need to investigate further.") the issue is probably related to Cura's settings.
I just renamed the old cura.cfg file (on my Antergos environment it's located in ~/.config/cura/4.1 directory - may be it differs for other distros) and started Cura with the Gui. With the wizzard created a new cura.cfg file.
The 'only' 'limitation' is: if I try to set up Support and Build Plate Adhesion Cura still crashes.
I assume the other cura.cfg in ~/.config/cura/4.0 should be renamed too to get a clear setup.
Warning: It's just a workaround which worked to me with limitations described above!
Last edited by gonczoll (2019-07-06 10:16:26)
Offline
so, right now, we don't have Cura on Arch Linux, right?
Seems to be so...
Offline
I'm not complaining (god forbid), but Cura had broken many times in the past. This time it was an opportunity for me to try out community/prusa-slicer. Slicer is a different app and it will take time to learn it, but it was a very simple print so it went well...also, no lag!
Last edited by eimis (2019-07-06 11:49:41)
Offline
....prusa-slicer. Slicer is a different app and it will take time to learn it, but it was a very simple print so it went well...also, no lag!
Thank you!
And: it's not that complicated/time wasting to switch from Cura to prusa-slicer - to me at least.
It works great on Arch Linux, just printed a calibration cube on Anet A8 with Octoprint.
Looks good!
Thank you for the hint!
Last edited by gonczoll (2019-07-06 13:07:57)
Offline
In the bugreport there are now some hacks described from T Friedel (tomee) wich worked to me. Cura works again.
"I also had the issue, so I also tried fiddling with the config file as Jelle suggested. In ~/.config/cura/4.1/cura.cfg removing the categories_expanded entry fixed the problem for me. After some more fiddling it turned out that just removing the following entries within categories_expanded was also enough:
support
speed_layer_0
platform_adhesion
When it runs again, you can disable some settings visibility as well to prevent crashes. I had to disable "Support Extruder" and "Build Plate Adhesion Extruder" "
Offline
Hm, not really an option imho
The only way to get Cura fully functional (and I really mean "fully") again for me was to downgrade my Qt libs to the state of before June.
I still had these in my pacman package cache so running a
cd /var/cache/pacman/pkg
pacman -U qt5-graphicaleffects-5.12.4-1-x86_64.pkg.tar.xz qt5-3d-5.12.4-1-x86_64.pkg.tar.xz qt5-base-5.12.4-2-x86_64.pkg.tar.xz pyqt5-common-5.12-2-x86_64.pkg.tar.xz python-pyqt5-5.12-2-x86_64.pkg.tar.xz qt5-datavis3d-5.12.4-1-x86_64.pkg.tar.xz qt5-declarative-5.12.4-1-x86_64.pkg.tar.xz qt5-location-5.12.4-1-x86_64.pkg.tar.xz qt5-multimedia-5.12.4-1-x86_64.pkg.tar.xz qt5-quickcontrols2-5.12.4-1-x86_64.pkg.tar.xz qt5-quickcontrols-5.12.4-1-x86_64.pkg.tar.xz qt5-script-5.12.4-1-x86_64.pkg.tar.xz qt5-scxml-5.12.4-1-x86_64.pkg.tar.xz qt5-sensors-5.12.4-1-x86_64.pkg.tar.xz qt5-serialport-5.12.4-1-x86_64.pkg.tar.xz qt5-speech-5.12.4-1-x86_64.pkg.tar.xz qt5-svg-5.12.4-1-x86_64.pkg.tar.xz qt5-webchannel-5.12.4-1-x86_64.pkg.tar.xz qt5-webengine-5.12.4-1-x86_64.pkg.tar.xz qt5-webkit-5.212.0alpha2-28-x86_64.pkg.tar.xz qt5-websockets-5.12.4-1-x86_64.pkg.tar.xz qt5-x11extras-5.12.4-1-x86_64.pkg.tar.xz qt5-xmlpatterns-5.12.4-1-x86_64.pkg.tar.xz
did the trick for me. I'm fully aware that this would eventually break other application dependencies / dependency chains but well time was too short to completely start over, e.g. on slic3r...
And yes, I also tried the fix suggested by Jooch in https://bugs.archlinux.org/task/63077#comment180418, unfortunately it didn't work even after removing everything.
Offline
Yes, it doesn't work fully here as well.
Its a pitty that former working app doesn't work since weeks and there are only random tries from users which work more or less.
I understand that Cura is not the most used SW in the Arch community but meanwhile at least a workaround would have been expected by the developers.
That's OK, that the community helps to localize failures but at the end developers are the ones who can fix them...
I miss this in this case.
Offline
https://github.com/Ultimaker/Cura/issue … -513266071
apparently cura only supports qt 5.10 , arch is at qt 5.13 now .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Online
they prolly dev on *ubuntus with old library versions
Offline
An update on Cura is available and it works again! (In the meantime I used PrusaSlicer instead and not sure why to go back to Cura. )
Offline
Seeing that a fix to Uranium from upstream fixed this problem (2019-07-28), I have marked this thread as solved
Offline