Cura: [4.0] Crash when clicking on "Preview"

Created on 23 Mar 2019 · 28Comments · Source: Ultimaker/Cura

Application Version
4.0

Platform
Linux

Clicking on "PREVIEW" in the main-window crashes the application. Last output from terminal:

2019-03-23 13:22:54,104 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/lib/cura/plugins/SimulationView/simulationview_composite.shader]...
Exception: cura killed by signal segmentation fault (core dumped)

Won't FiDo

Source

muesli

👍2

Most helpful comment

@ngdio - themes are a very likely candidate.

When I use QT_QUICK_CONTROLS_STYLE=material cura, cura no longer crashes, and the UI layout is also no longer broken.

Reported it for KDE, https://bugs.kde.org/show_bug.cgi?id=417900

StefanBruens on 20 Feb 2020

👍4

All 28 comments

I have the same problem (Archlinux, Cura 4.0).

Johannes128 on 24 Mar 2019

Try the AppImage.

fieldOfView on 24 Mar 2019

👍1

The AppImage works. I will report the bug to the package maintainer of cura on Archlinux. Thank you very much!

Johannes128 on 25 Mar 2019

Thans for reporting anyway!

rburema on 26 Mar 2019

@Johannes128 has this been fixed in Arch already? I'm running into the same issue on Gentoo but I can't figure out what package / dependency is causing it.

MathyV on 28 Mar 2019

@MathyV I'm not sure if anything has been fixed in their repo's, but the AppImage should work for all distro's, since it has the dependencies baked in. It's also the only one we (at Ultimaker at least) support.

rburema on 28 Mar 2019

The AppImage works for me too, I'm however trying to create a working Gentoo package. I understand you only support AppImage but I'm looking for pointers what could be the possible reason, both the debug and strace don't tell me a lot, it fails in the call to load the shaders, that's it. I'm thinking in the direction of an outdated or too new dependency but I can't pinpoint it.

MathyV on 28 Mar 2019

@MathyV I know we've had some problems with Qt, locking us into a specific version on both sides for different reasons. (We're on 5.10.) You can also take a look at cura-build-environment and cura-build for inspiration.

rburema on 28 Mar 2019

Ah, I previously locked PyQt5 on 5.9 because 3.x didn't build with 5.10. I'll check, thanks for the pointer.

MathyV on 28 Mar 2019

@MathyV You might even specifically need 5.10.0

rburema on 28 Mar 2019

@MathyV No, up until now, the issue still persists on my machine on Arch... Arch currently uses PyQt 5.12.1 and Qt 5.12.2.

Johannes128 on 28 Mar 2019

I tried with 5.10.1 which is in the Gentoo portage tree but now it doesn't even start, I get a Connection reset by peer from the Backend. I will investigate further.

This by the way is the exact reason I switched back to PyQt 5.9

MathyV on 28 Mar 2019

I know for both Windows and Linux at least, that we _specifically_ set pip (not any package manager) to install PyQt=5.10.0

So that would be (sudo) pip3 install PyQt5==5.10.0

rburema on 28 Mar 2019

I'm running from source using PyQt 5.12.1 and Qt 5.12.2 on Ubuntu 18.10, and it's working fine for me. It must be possible to set it up with a more modern [Py]Qt version just as well. Of course, we can't guarantee that it's going to stay that way if Qt makes breaking changes in their future versions, but so far it appears to work okay with modern Qt versions.

Ghostkeeper on 28 Mar 2019

@Ghostkeeper did you install PyQt through system or through pip?

The crash with 5.10.1 is related to this issue: https://github.com/Ultimaker/Cura/issues/3438, so I switched to PyQt 5.12.1 which includes the necessary fix and now Cura starts again but preview is still not working, like with @Johannes128. I'm now going to check with debugging symbols to see if gdb can tell me something useful.

MathyV on 28 Mar 2019

Completely by accident I discovered that if I run cura as root, it actually works. To be sure it was not just the fact that I never used as root before I created an empty user profile with identical permissions to my regular user and for sure it also doesn't work, so the root elevation seems to solve whatever is segfaulting.

I can't explain why this is happening though. Running the AppImage from my user works, running it from the system binaries doesn't. I can't seem to find some way that root elevation is happening in the AppImage so the permissions should be exactly the same.

MathyV on 28 Mar 2019

The problem really seems to be situated in SimulationView, if I disable that in the source code I can actually open the Preview tab and the XRayView works properly. I've tried to find a difference between the two that could explain this but didn't really come up with anything.

I tried a quick import of just Cura into PyCharm to debug this further but that didn't work, I guess I'll have to go the full monty in order to make that work. There's only so much you can do from a command-line :-)

MathyV on 28 Mar 2019

@Ghostkeeper did you install PyQt through system or through pip?

Neither, I compiled it myself and installed PyQt to my Python environment.

I tried a quick import of just Cura into PyCharm to debug this further but that didn't work,

Anything to do with PyCapsule_GetPointer having an incorrect name? I'm getting that when I run via PyCharm's debug mode.

Ghostkeeper on 29 Mar 2019

@MathyV I also tried to run Cura as root on Arch and it worked! If you find out what's causing the issue please let us know.

Johannes128 on 29 Mar 2019

Maybe it's storing the configuration settings somewhere that you don't have write access to normally? Cura normally uses ~/.config, ~/.local and ~/.cache.

Ghostkeeper on 29 Mar 2019

Similar to @MathyV I am getting issue with Cura 3.6/4.0 on Gentoo using PyQt 5.12.1

Stack Trace as normal user per the below. Wondering if it might be related to Qt Quick similar to QTBUG-67839

2019-04-08 03:56:02,295 - DEBUG - [MainThread] UM.Controller.setActiveStage [159]: Setting active stage to PreviewStage
2019-04-08 03:56:02,307 - DEBUG - [MainThread] UM.Controller.setActiveView [92]: Setting active view to SimulationView
2019-04-08 03:56:02,308 - INFO - [MainThread] STLReader.STLReader.load_file [54]: Using legacy code to load STL data.
2019-04-08 03:56:02,353 - DEBUG - [MainThread] UM.Mesh.MeshData.calculateNormalsFromVertices [444]: Calculating normals took 0.0006914138793945312 seconds
2019-04-08 03:56:02,364 - DEBUG - [MainThread] UM.Mesh.MeshData.approximateConvexHull [401]: approximateConvexHull(target_count=1024) Calculating 3D convex hull took 0.009788274765014648 seconds. 351 input vertices. 351 output vertices.
2019-04-08 03:56:02,364 - DEBUG - [MainThread] STLReader.STLReader._read [97]: Loaded a mesh with 12612 vertices
2019-04-08 03:56:02,366 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/lib/cura/plugins/SimulationView/simulationview_composite.shader]...

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007fffe1a58bd4 in ?? () from /usr/lib64/libQt5Quick.so.5
(gdb) backtrace
#0  0x00007fffe1a58bd4 in ?? () from /usr/lib64/libQt5Quick.so.5
#1  0x00007fffe1a59303 in QQuickItem::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libQt5Quick.so.5
#2  0x00007fffd3d977d5 in QQuickControl::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libQt5QuickTemplates2.so.5
#3  0x00007fffe7101a3d in QQmlVMEMetaObject::metaCall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib64/libQt5Qml.so.5
#4  0x00007fffe70606f1 in QV4::QObjectWrapper::setProperty(QV4::ExecutionEngine*, QObject*, QQmlPropertyData*, QV4::Value const&) () from /usr/lib64/libQt5Qml.so.5
#5  0x00007fffe706118e in QV4::QObjectWrapper::setQmlProperty(QV4::ExecutionEngine*, QQmlContextData*, QObject*, QV4::String*, QV4::QObjectWrapper::RevisionMode, QV4::Value const&) () from /usr/lib64/libQt5Qml.so.5
#6  0x00007fffe7061326 in QV4::QObjectWrapper::virtualPut(QV4::Managed*, QV4::PropertyKey, QV4::Value const&, QV4::Value*) () from /usr/lib64/libQt5Qml.so.5
#7  0x00007fffe70dc1b6 in QV4::Runtime::method_storeProperty(QV4::ExecutionEngine*, QV4::Value const&, int, QV4::Value const&) () from /usr/lib64/libQt5Qml.so.5
#8  0x00007fff62d5529f in ?? ()
#9  0x0000000000000000 in ?? ()

Running as root, Cura works as expected, but is obviously not a long term solution.

2019-04-08 01:28:34,221 - DEBUG - [MainThread] UM.Controller.setActiveStage [159]: Setting active stage to PreviewStage
2019-04-08 01:28:34,248 - DEBUG - [MainThread] UM.Controller.setActiveView [92]: Setting active view to SimulationView
2019-04-08 01:28:34,250 - INFO - [MainThread] STLReader.STLReader.load_file [54]: Using legacy code to load STL data.
2019-04-08 01:28:34,316 - DEBUG - [MainThread] UM.Mesh.MeshData.calculateNormalsFromVertices [444]: Calculating normals took 0.0029249191284179688 seconds
2019-04-08 01:28:34,337 - DEBUG - [MainThread] UM.Mesh.MeshData.approximateConvexHull [401]: approximateConvexHull(target_count=1024) Calculating 3D convex hull took 0.019352436065673828 seconds. 351 input vertices. 351 output vertices.
2019-04-08 01:28:34,339 - DEBUG - [MainThread] STLReader.STLReader._read [97]: Loaded a mesh with 12612 vertices
2019-04-08 01:28:34,342 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/lib/cura/plugins/SimulationView/simulationview_composite.shader]...
2019-04-08 01:28:34,407 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [352]: file:///usr/lib/cura/plugins/PreviewStage/PreviewMain.qml:22:5: QML ActionPanelWidget: Binding loop detected for property "width"
2019-04-08 01:28:34,468 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/share/uranium/resources/shaders/color.shader]...
2019-04-08 01:28:34,477 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/lib/cura/plugins/SimulationView/layers3d.shader]...
2019-04-08 01:28:34,552 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/lib/cura/plugins/SimulationView/layers3d_shadow.shader]...
2019-04-08 01:28:34,612 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/share/uranium/resources/shaders/toolhandle.shader]...
2019-04-08 01:28:34,619 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [55]: Loading shader file [/usr/share/uranium/resources/shaders/color.shader]...

miland3r on 7 Apr 2019

Running the AppImage works as expected and is the longterm solution.

fieldOfView on 8 Apr 2019

👎12 👍2

@fieldOfView Do you really suggest running pre-compiled binary images as a longterm solution? I find this rather cringeworthy.

muesli on 8 Apr 2019

I don't. So either you use the exact same versions of libraries we test for, or you use the packaged things that we provide. There really isn't any other feasible way for us to ensure that everything works otherwise (yes, in theory, if all libraries that we use do the compatibility dance perfectly everything works. But that is never the case)

nallath on 8 Apr 2019

@nallath That's going to be tough, in particular if you're depending on versions of those deps that have been released years ago. I'm not asking you to "officially support" packages or self-compiled versions, but these issues could still be treated as valid feedback. They're usually a good indicator for problems you're going to face with your own builds in the near future, and at least you then got a head-start with some (potentially) valuable debug information someone provided.

Last but not least, this is essentially excluding external contributors from the project. I'm not sure how I'm supposed to test my changes if I can't run my own builds. I'm aware of the Wiki pages (e.g. https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Ubuntu), but frankly that's how we ended up with these tickets in the first place.

muesli on 8 Apr 2019

👍3

Sure, we are going to help you get the builds running, but we do have to put the line somewhere. I guess it's a matter of guaranteeing what works (eg; We pretty much ensure that what we ship works) vs whatever someone cobbled together and wants to get working.

I do see the issues as valid feedback and we do spend time on them (as much as possible). The main reason for it is that the feedback from people that have the knowhow to put their own version together tends to be of a much, much higher quality (I mean, i seriously love the fact that issues from you guys already have research / logs / different attempts that didn't work attached to them. Just have a look at some of the low quality of issues that some people post)

We're right now going to look into when / how we are switching to the latest Qt, mostly because a number of you reported issues with 5.12 (making it likely that we will skip that version).

Apart from that, we're also working on exposing our build systems more and making it less of a monolithic process, but this is a lot of work.

nallath on 8 Apr 2019

👍2

Is this possibly connected to custom Qt themes? When running Cura as root, themes set by your desktop environment are not being used, so Cura works flawlessly. KDE's Breeze theme renders Cura pretty much useless anyway since multiple UI options aren't being correctly, some buttons cannot be pressed. Perhaps forcing the standard theme for Cura would be a possible workaround? Looks better anyway.