Cura: Crashing on startup

[Xinayder]

Application version
4.1.0

Platform

• Arch Linux x86_64 5.2.0-arch2-1-ARCH
• Intel i5 3570k
• NVIDIA GTX 970

Printer
Creality Ender 3

Reproduction steps

1. Launch Cura

Actual results
After a few seconds, the program will close without an error. Looking at the console, there's a segmentation fault happening when loading some plugins.

Expected results
Cura should start.

Additional information
Log file: https://pastebin.com/LN6xGhbY

Arch Linux related bug report: https://bugs.archlinux.org/task/63077

[mswdev]

Same issue here

[Mikerhinos]

Affected too.

Cura 4.1

Manjaro Linux (Arch based)
Intel i5
NVIDIA GTX 1060

Creality CR10S Pro

Cura starts and works for a couple of minutes if run in SU, after that the segmentation fault kicks in.

[smartavionics]

Hi Folks, unless you are using the Ultimaker AppImage it is unlikely that this issue will see much attention. Of course, if you determine what is going wrong and submit a PR to fix the problem, it would be accepted (assuming it doesn't cause any other issues).

[Xinayder]

@smartavionics This sucks because it's an issue with the current code. v4.0 was fine. As you can see in the Arch Linux bug report, it's either caused by plugins (my issue) or categories_expanded on the settings.

[smartavionics]

The problem is that the Ultimaker team (and us contributors) don't have the spare capacity to track down and fix problems with builds that differ from the standard release. I'm sure they would like this problem to be fixed but I doubt if they have the resources available to investigate it.

Why can't you use the AppImage? is it not compatible with your system?

[Mikerhinos]

For me, Appimage is very slow to open, and is not auto updated.

Managed to get Arch/Manjaro version (isn't it just a script building from Git repo ?) working by launching Appimage, told me that my settings were corrupted so I reset it, launched Arch version and then it worked.
Though if I sign in on my Ultimaker account and import my cloud save, Cura won't slice no matter the printer/profile/settings I use.
So I just use it as a "fresh install", hoping that it will be fixed in a future release so I can get back all my past settings (and started to learn PrusaSlicer in case it's not lol).

[Ghostkeeper]

The segfault for RockyTV is happening when the main window is loaded, not while the plug-ins are being loaded. Though granted, it's also complaining about missing dependencies during plug-in loading (libCharon and Zeroconf). Since it's happening while the main window is loading, it's most likely an issue with your version of Qt, i.e. not version 5.10 which we maintain.

[smartavionics]

I don't normally use the appimages that I build because my cura installation also exists as a regular file tree. But when I do open the appimage, it's not terribly slow. Of course, you could unpack the appimages into a file tree which would make them faster to execute.

[Xinayder]

Why can't you use the AppImage? is it not compatible with your system?

I prefer using my system's package manager to manage package versions, instead of having to download a new AppImage every time and having different versions of the same software installed.

it's also complaining about missing dependencies during plug-in loading (libCharon and Zeroconf)

That's weird, did the required dependencies change from 4.0.0 to 4.1.0?

Since it's happening while the main window is loading, it's most likely an issue with your version of Qt, i.e. not version 5.10 which we maintain.

I just checked the dependencies required by the Arch package and they're all on version 5.13. I'll try using an older version. Also, is there anything else I can do to provide you more information about the segfaults?

[khumarahn]

same here on arch linux

[mswdev]

Why can't you use the AppImage? is it not compatible with your system?
@smartavionics

I agree with @RockyTV.
Linux distributions such as Arch, Manjaro, and many others use package managers to install packages/programs such as Cura in this case. Packages/programs should never really be installed directly from the provider unless it is a last resort.

In this case, Cura has been managed through the AUR, Manjaro and many other pakcage managers for quite a long time and this has not become an issue until the last Cura update.

[mswdev]

Here is a video of the issue occurring. As you can see it crashes when the categories expanded "Support Extruder" and "Build Plate Adhesion Extruder" are expanded.

I manually disabled these so you could see in the video that it happens when those are expanded.
https://streamable.com/s/p13eu

[nallath]

The main problem with package managers that we've had is that older packages that we relied on (eg; we require a very specific version of certain libraries) were suddenly no longer available, causing Cura to no longer be installable.
It's also not quite feasible for us to support all different options out there. It's already hard enough for us to defend supporting Linux with what few users we have.

[jypma]

I think I have a backtrace of the SIGSEGV here:

#0  0x00007fb21b6ed755 in raise () at /usr/lib/libc.so.6
#1  0x00007fb21b6ed7e0 in <signal handler called> () at /usr/lib/libc.so.6
#2  0x0000000000000000 in  ()
#3  0x00007fb2175006ca in QMetaObject::cast(QObject const*) const () at /usr/lib/libQt5Core.so.5
#4  0x00007fb2116b0232 in QQuickOpenGLShaderEffectCommon::disconnectPropertySignals(QQuickItem*, QQuickOpenGLShaderEffectMaterialKey::ShaderType) () at /usr/lib/libQt5Quick.so.5
#5  0x00007fb2116b331d in QQuickOpenGLShaderEffect::~QQuickOpenGLShaderEffect() () at /usr/lib/libQt5Quick.so.5
#6  0x00007fb2116b33da in QQuickOpenGLShaderEffect::~QQuickOpenGLShaderEffect() () at /usr/lib/libQt5Quick.so.5
[...]
#35 0x00007fb2174f65ec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#36 0x00007fb2174fe326 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
[...]

So it's something with Qt or OpenGL... any recent changes there?

[mswdev]

The main problem with package managers that we've had is that older packages that we relied on (eg; we require a very specific version of certain libraries) were suddenly no longer available, causing Cura to no longer be installable.

I've never had problems with Cura previously in terms of this until now.

It's also not quite feasible for us to support all different options out there. It's already hard enough for us to defend supporting Linux with what few users we have.

Thought processes like this are the reason why so many people are held back from using Linux. There are many solutions available to easily deploy products to various platforms without hassle.

This bug is severe in terms that it completely hinders the use of Cura as users cannot launch the program unless those specific expanded options are disabled.

[Ghostkeeper]

There are many solutions available to easily deploy products to various platforms without hassle.

Yet here we are, having the hassle of dealing with versions of Qt that we never tested the application on. Indeed it's very space-efficient for the users to keep only one version of every library and easy to use only one system for managing packages. But for us, upgrading Qt versions is a significant risk of breaking random things all over the UI (like menus suddenly having no height or width in 5.12, or this segfault in 5.13), so everything in the UI would have to be tested for every Qt version, which adds at least 20% to the development time and 40% for the QA team. So we want only one version of Qt, and currently that has to be 5.10 or we'd drop support for older MacOS versions that are still in use.

[nallath]

I understand that it's holding things back. I'm not a fan of the current situation either. But less than 1% of our users are on Linux. We simply can't defend having to spend 20-40% additional QA efforts into supporting that, especially since the appimage works just fine.

[kyrios123]

Perhaps this patch from openSUSE can help ?

[Ghostkeeper]

If that resolves the issue we'd gladly merge it. You should be able to modify the CuraApplication.py file (with root access) in your AUR package installation, right?

[kyrios123]

@Ghostkeeper I'm not a ArchLinux user and I'm not the author of the patch too. I was looking for a solution for a slightly different problem when I found it so I thought I'd share it here as at first sight it might be a fix for this issue... just in case it can help someone.

[ValeriyKoloytanov]

Jelle van der Waa (https://github.com/jelly) is a maintainer of an Arch package.To add to that Cura is not an AUR package.It is available in official "community" repository

[mswdev]

Perhaps this patch from openSUSE can help ?

I'll try that when I get home and let you guys know! Also, there was an update for Uranium python framework this morning so I'll update that to see if it does anything.

[j00ch]

@kyrios123 Tried the patch, compiled without any issues, but no luck I'm afraid :cry:

[Xinayder]

We simply can't defend having to spend 20-40% additional QA efforts into supporting that, especially since the appimage works just fine.

If that resolves the issue we'd gladly merge it.

I really appreciate what you're doing. And I do understand that supporting package managers requires more work from you.

However, as stated by different users here and on the Arch Linux bug tracker, it seems like some settings are causing the segfault, and it's certainly related to Qt 5.13 and OpenGL. I'd like to share that 5.12 worked just fine with version 4.0.0, and as soon as I updated to 4.1.0 and Qt to 5.13, it stopped working.

I've also tested the patch from openSUSE and it didn't work either, same problem as before. I also tried compiling from git using the cura-git package and the issue is still present.

[j00ch]

it's certainly related to Qt 5.13 and OpenGL

It certainly is, just tried on my old laptop with Nvidia's propriety driver, works fine. All my systems running open source video drivers are broken. BTW i just noticed all QT apps requiring HW acceleration are broken at this moment. So is QT at fault, OpenGL or the video drivers?

[mswdev]

it's certainly related to Qt 5.13 and OpenGL

It certainly is, just tried on my old laptop with Nvidia's propriety driver, works fine. All my systems running open source video drivers are broken. BTW i just noticed all QT apps requiring HW acceleration are broken at this moment. So is QT at fault, OpenGL or the video drivers?

I'm running the proprietary Nvidia drivers and it does not work. So then it has to be an issue with QT? I'm running QT 5.13 as well

[j00ch]

I have an older nvidia driver on my laptop (340xx).

There was an update of mesa/xorg today, now everything works on my other systems. Could you check?

[lucaspiller]

It's still not working for me with integrated Intel graphics. Has anyone tried downloading QT to see if that helps?

2019-07-18 15:13:06,483 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [100]: OpenGL Version:  4.5 (Core Profile) Mesa 19.1.2
2019-07-18 15:13:06,484 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [101]: OpenGL Vendor:   Intel Open Source Technology Center
2019-07-18 15:13:06,484 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [102]: OpenGL Renderer: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) 

[lucaspiller]

I attempted moving my Cura directory out of the way, and it started working.

I tried debugging the config file, and removing the active_machine = .... line launches Cura properly. It then asks me to go through the on-boarding and add a new machine, but after doing this I can select the old machine and make prints. If I then close and relaunch Cura it will crash on launch.

Here is the crash log and my cura.cfg:

https://gist.github.com/lucaspiller/b295349f6c130eb60074973d2ae5050f

It seems like this is a bug in Cura rather than a bug in QT.

[j00ch]

I found that mesa was crashing opengl somehow, but with the update that seems fixed. I'll try my old profile when i get back. See what happens then.

[j00ch]

Profile crash confirmed, i didn't bother debugging that. Just removed my profile data and started over.

[j00ch]

I found that expanding infill options from the menu instantly crashes Cura, can anyone confirm?

[lucaspiller]

Yeah I've just noticed this too. Even searching for "infill" triggers it. I can print fine until I do that though :D

[schmidtbag]

I'm pretty confident this isn't a problem with Cura, at least not entirely. I tried running Cura 4.1.0 on a Debian Buster setup and it works fine even when trying to provoke stuff known to cause crashes. But when I just simply expand Infill or Support options in Arch, it crashes. Cura 4.1.0 _was_ working fine for me on Arch when it was first released, so, it's not necessarily an Arch problem either.
Both my Debian and Arch setups are using modern CPUs and GCN 1.1 GPUs. Considering both Nvidia and Mesa users are getting issues, I think we can eliminate this being an OpenGL problem; their implementations for OpenGL are different.

That just leaves us with Qt as the only outlier, and frankly, Qt seems to have a knack for breaking things lately. Qt has been updated in Arch within the past month. Arch is using Qt 5.13, while my Debian setup is using 5.11. I don't have access to my Arch setup at the moment, but if anyone can test downgrading to 5.11, that might help us prove what's actually at fault here.

I guess what we should ask of the Cura devs is: what's the newest version of Qt you have tested with?

[fieldOfView]

Cura is only tested (and supported) with Qt 5.10, though some developers use it with newer versions.

[j00ch]

Cura is only tested (and supported) with Qt 5.10, though some developers use it with newer versions.

5.10 has been archived for a while, 5.11 is archived too. Arch's package archive doesn't go back further than 5.12, which makes sense since it is still supported by QT.

When i look in RecommendedInfillDensitySelector.qml it imports:
import QtQuick 2.7 import QtQuick.Controls 1.4 import QtQuick.Controls.Styles 1.4

That corresponds to QT 5.6, such a big gap is asking for trouble. So yes QT is crashing (qt5-quickcontrols to be exact), but saying QT is at fault might be a stretch.

Other settings tabs that use the same imports crash too (support, adhesion). Maybe changing/updating to a different combination could fix this?

[fieldOfView]

AFAIK, the problem with switching to a newer version of Qt means dropping support for older versions of OSX. I am guessing that the number of users of Cura using those older versions of OSX is higher than the number of users of Cura on Arch.

[smartavionics]

So is it absolutely impossible for Cura to use one version of Qt for OS X and another version for Windows & Linux? Are the differences between the APIs so great that they cannot easily be worked around?

[schmidtbag]

AFAIK, the problem with switching to a newer version of Qt means dropping support for older versions of OSX. I am guessing that the number of users of Cura using those older versions of OSX is higher than the number of users of Cura on Arch.

I'm actually not so sure how right you are about that. As of right now, the _only_ people using Mac OS 10.11 are those who either:
A. Don't pay attention to updates (in which case, they wouldn't notice a newer version of Cura)
B. Have a Core2-based Mac computer built in 2009 or earlier.
Arch users with Cura are very niche, but I think using some crappy old Mac that has already reached EOL 4 years ago is even moreso. It is only a matter of time until other distros and other OSes update to a newer version of Qt. Arch just happens to be an early adopter.
Bear in mind, there are other Core2-based Macs that can update to 10.13, which supports the newest version of Qt.

In another perspective:
Qt is going to continue moving forward whether Mac OS 10.11 supports it or not. At some point, Cura attempting to retain that support of that OS is going to become a burden to anyone who uses Qt for other purposes regardless of which OS they use.

Qt is open source. In my personal opinion, if anyone really wants to run the latest version of Cura on a dead device, they either need to install a different OS or they need to compile a newer version of Qt.

[fieldOfView]

So is it absolutely impossible for Cura to use one version of Qt for OS X and another version for Windows & Linux?

Absolutely impossible? No. But since there seem to be QML rendering differences between Qt 5.10 and 5.13, it would mean a substantial increase in writing and testing version-specific code.

I'm actually not so sure how right you are about that

I'm just a community member like you and I don't have access to usage data either. I just happen to remember the backlash of actual Ultimaker customers when the change to Qt 5.10 was made because that also stopped support for certain versions of OSX.

Qt is open source. In my personal opinion, if anyone really wants to run the latest version of Cura on a dead device, they either need to install a different OS or they need to compile a newer version of Qt.

So, why wouldn't that argument work the other way around? Cura is open source. I think that by the mere fact that we are having this conversation on github, you are more capable of contributing fixes for running Cura with Qt 5.13 through the Arch community package than most Ultimaker customers running OSX are capable of compiling a newer version of Qt on older systems (and writing workarounds for functionality that is simply missing in those older systems).

[schmidtbag]

I'm just a community member like you and I don't have access to usage data either. I just happen to remember the backlash of actual Ultimaker customers when the change to Qt 5.10 was made because that also stopped support for certain versions of OSX.

Fair enough. I guess at this point you have to weigh whether these customers using EOL devices are more important than what will be (but currently is not) everyone else. There's still time to make a decision, but like I said earlier, Arch is just the beginning. This problem _will_ spread, so, I think it's good to heed the warning that Arch has brought to our attention.
If retaining support for older devices is deemed necessary, then perhaps the code could perform checks for which version of Qt is in use, and change its behavior accordingly. So far, it just seems like the Infill and Support functions are broken, so these behavior checks aren't going to be all that common. So really I don't think any code needs to be scrapped; there just needs to be something new to work beside the old stuff. That way, everybody wins.

So, why wouldn't that argument work the other way around? Cura is open source. I think that by the mere fact that we are having this conversation on github, you are more capable of contributing fixes for running Cura with Qt 5.13 through the Arch community package than most Ultimaker customers running OSX are capable of compiling a newer version of Qt on older systems (and writing workarounds for functionality that is simply missing in those older systems).

The argument doesn't work the other way around because the subjects at hand are heading in opposite directions. In one case, you have an EOL computer that is [ostensibly] capable of running a newer version of Qt, but because it's old, nobody from Qt built it. So, that means the user has to, and that's all the user needs to do to retain support for Cura.
In the other scenario, you're expecting users to make a fork of the main repo and modify the code themselves, regardless of whether it goes upstream. Those modifications are inevitable: eventually, everyone but the old Mac users will need it, so in my opinion, Arch doing their own one-off solution is just wasting time for everyone not using Arch or an old Mac.
This is only an Arch-specific issue today, but it won't remain that way. So, in my opinion, it's best that the changes are done in the main branch, so everyone will benefit.

[smartavionics]

BTW, on arch with qt 5.13, what version of pyqt are you using? Thanks.

[schmidtbag]

BTW, on arch with qt 5.13, what version of pyqt are you using? Thanks.

5.13.0-1
There's also a python-sip-pyqt5 package at version 4.19.18-1, if that makes a difference to you.

[Xinayder]

Cura is only tested (and supported) with Qt 5.10, though some developers use it with newer versions.

Cura 4.0.0 worked fine with Qt 5.12. I believe the current version (4.1.0) will work with Qt 5.12. The problem is downgrading Qt packages when you have different software that uses them.

One guy from #pyqt IRC channel recommended me to install a pyenv and try to run Cura with pyqt5 5.12. I'm still trying to get it working.

[smartavionics]

Small news. I have just finished building cura using Qt 5.13 and PyQt 5.13 on a Pi 4 system using a remote X display. It runs (rather slowly as you can imagine) and even slices a benchy(!) OK. It did bomb when opening one of the settings panels (which I think others have seen). Over the next few days I will be seeing if I can track down the reason(s) for the segfault.

The reason I am using the Pi 4 is simply because it's the only other Linux system I have at my immediate disposal.

[schmidtbag]

Small news. I have just finished building cura using Qt 5.13 and PyQt 5.13 on a Pi 4 system using a remote X display. It runs (rather slowly as you can imagine) and even slices a benchy(!) OK. It did bomb when opening one of the settings panels (which I think others have seen). Over the next few days I will be seeing if I can track down the reason(s) for the segfault.

The reason I am using the Pi 4 is simply because it's the only other Linux system I have at my immediate disposal.

Out of curiosity, do you get the same problem on Windows or Mac when using Qt 5.13 (and PyQt 5.13)? Because you might not have to deal with the slowness of a Pi4 if this issue applies to everything (as I suspect it does).

[mswdev]

AFAIK, the problem with switching to a newer version of Qt means dropping support for older versions of OSX. I am guessing that the number of users of Cura using those older versions of OSX is higher than the number of users of Cura on Arch.

I'm actually not so sure how right you are about that. As of right now, the _only_ people using Mac OS 10.11 are those who either:
A. Don't pay attention to updates (in which case, they wouldn't notice a newer version of Cura)
B. Have a Core2-based Mac computer built in 2009 or earlier.
Arch users with Cura are very niche, but I think using some crappy old Mac that has already reached EOL 4 years ago is even moreso. It is only a matter of time until other distros and other OSes update to a newer version of Qt. Arch just happens to be an early adopter.
Bear in mind, there are other Core2-based Macs that can update to 10.13, which supports the newest version of Qt.

In another perspective:
Qt is going to continue moving forward whether Mac OS 10.11 supports it or not. At some point, Cura attempting to retain that support of that OS is going to become a burden to anyone who uses Qt for other purposes regardless of which OS they use.

Qt is open source. In my personal opinion, if anyone really wants to run the latest version of Cura on a dead device, they either need to install a different OS or they need to compile a newer version of Qt.

I completely agree with this.

[smartavionics]

Out of curiosity, do you get the same problem on Windows or Mac when using Qt 5.13 (and PyQt 5.13)? Because you might not have to deal with the slowness of a Pi4 if this issue applies to everything (as I suspect it does).

I can't build cura anymore on my ancient mac book and the windows machine I build my releases on is slower than the Pi! Also, I never use windows otherwise so it's much easier to work on this on a linux box.

[smartavionics]

I am trying to use a debug build of Qt but it's crashing on startup with the following assert fail:

ASSERT failure in QSGNode::appendChildNode: "QSGGeometryNode is missing material", file scenegraph/coreapi/qsgnode.cpp, line 444

I would be grateful if any Cura dev could say whether they can normally run cura using a debug version of qt OK and if so, do they have any suggestions as to how I can track down this problem.

[fieldOfView]

This may be unrelated, but yhe only place that Cura directly uses QSGGeometryNode is in the PointingRectangle class. Guess who's to blame?

https://github.com/Ultimaker/Uranium/blame/master/UM/Qt/Bindings/PointingRectangle.py

[Ghostkeeper]

If retaining support for older devices is deemed necessary, then perhaps the code could perform checks for which version of Qt is in use, and change its behavior accordingly.

We don't need to, because we package Cura in such a way that we always supply the same Cura version. This reduces the amount of testing we need to do because we only need to test on one GUI framework rather than many.

In the other scenario, you're expecting users to make a fork of the main repo and modify the code themselves, regardless of whether it goes upstream.

I'm still hoping that if a modification can be made, the user that makes the modification also posts it upstream so that other Arch users won't need to modify anything. Most likely this is a bug in Qt 5.10 that Cura is happening to trigger at some point, so if there is a workaround that would be fine. I agree that it should go upstream, as long as the modification still works in 5.10 as well.

I would be grateful if any Cura dev could say whether they can normally run cura using a debug version of qt OK and if so, do they have any suggestions as to how I can track down this problem.

@nallath is running a debug version of Qt. I must say that I've seen that error message before, somewhere... Don't know where though, and search engines don't make me any wiser.

[Ghostkeeper]

Maybe it's an idea to replace the QSGGeometryNode with a simple SVG icon that we rotate?

[smartavionics]

This may be unrelated, but yhe only place that Cura directly uses QSGGeometryNode is in the PointingRectangle class. Guess who's to blame?

Cool, is there a quick fix that can be done there?

[fieldOfView]

As a quick way to try if this is indeed the problem, you could rename the updatePaintNode method to something else. That will stop the pointing rectangles from drawing, so tooltips and tool panels will not have a background. But at least we should know if this is indeed part of the problem.

[smartavionics]

So, interesting. Aldo, I did what you suggested and it doesn't now crash as I mention above. Interestingly, it's not also crashing (so far) when I open and close the setting drop-downs which it has been doing until now. Perhaps I need to do that more but, previously, it crashed pretty quickly. I then went on to load a project and it then did crash with the following gdb backtrace. Does any of that say anything useful?
````

0 0x00000018 in ?? ()

1 0xaaba0208 in QMetaObject::cast (this=0xaaef0784 ,

this@entry=0xa7e6d22c <QQuickOpenGLShaderEffectCommon::disconnectPropertySignals(QQuickItem*, QQuickOpenGLShaderEffectMaterialKey::ShaderType)+408>, obj=0x4a36b48)
at kernel/qmetaobject.cpp:374

2 0xaaba0238 in QMetaObject::cast (

this=this@entry=0xa7e6d22c <QQuickOpenGLShaderEffectCommon::disconnectPropertySignals(QQuickItem*, QQuickOpenGLShaderEffectMaterialKey::ShaderType)+408>, obj=<optimized out>)
at kernel/qmetaobject.cpp:363

3 0xa7e6d22c in qobject_cast (object=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtbase/include/QtCore/../../src/corelib/kernel/qobject.h:502

4 QtPrivate::QVariantValueHelper::object (v=...)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:737

5 QtPrivate::ObjectInvoker, QVariant const&, QObject*>::invoke (a=...)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:108

6 qvariant_cast (v=...) at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:865

7 QQuickOpenGLShaderEffectCommon::disconnectPropertySignals (this=this@entry=0x4ed8bfc, item=0x5d94940, shaderType=shaderType@entry=QQuickOpenGLShaderEffectMaterialKey::FragmentShader)

at items/qquickopenglshadereffect.cpp:234

8 0xa7e701ac in QQuickOpenGLShaderEffect::~QQuickOpenGLShaderEffect (this=0x4ed8bc0, __in_chrg=) at items/qquickopenglshadereffect.cpp:656

9 0xa7e702ec in QQuickOpenGLShaderEffect::~QQuickOpenGLShaderEffect (this=0x4ed8bc0, __in_chrg=) at items/qquickopenglshadereffect.cpp:653

10 0xaabd3338 in QObjectPrivate::deleteChildren (this=this@entry=0x2ce7570) at kernel/qobject.cpp:2019

11 0xaabd4908 in QObject::~QObject (this=, __in_chrg=) at kernel/qobject.cpp:1032

12 0xa7d07fa4 in QQuickItem::~QQuickItem (this=0x5d94940, __in_chrg=) at items/qquickitem.cpp:2443

13 0xa7d3142c in QQuickShaderEffect::~QQuickShaderEffect (this=0x5d94940, __in_chrg=) at items/qquickshadereffect_p.h:67

14 QQmlPrivate::QQmlElement::~QQmlElement (this=0x5d94940, __in_chrg=) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:108

15 QQmlPrivate::QQmlElement::~QQmlElement (this=0x5d94940, __in_chrg=) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:108

16 0xaabd3338 in QObjectPrivate::deleteChildren (this=this@entry=0x4710f60) at kernel/qobject.cpp:2019

17 0xaabd4908 in QObject::~QObject (this=, __in_chrg=) at kernel/qobject.cpp:1032

18 0xa7d07fa4 in QQuickItem::~QQuickItem (this=0x6c43080, __in_chrg=) at items/qquickitem.cpp:2443

19 0xa7d3169c in QQmlPrivate::QQmlElement::~QQmlElement (this=0x6c43080, __in_chrg=) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:106

20 QQmlPrivate::QQmlElement::~QQmlElement (this=0x6c43080, __in_chrg=) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:108

21 0xaabd3338 in QObjectPrivate::deleteChildren (this=this@entry=0x77dc240) at kernel/qobject.cpp:2019

22 0xaabd4908 in QObject::~QObject (this=, __in_chrg=) at kernel/qobject.cpp:1032

23 0xa7d07fa4 in QQuickItem::~QQuickItem (this=0x6749e08, __in_chrg=) at items/qquickitem.cpp:2443

24 0xa7d70f0c in QQuickImplicitSizeItem::~QQuickImplicitSizeItem (this=0x6749e08, __in_chrg=) at items/qquickimplicitsizeitem_p.h:60

25 QQuickText::~QQuickText (this=0x6749e08, __in_chrg=) at items/qquicktext.cpp:1321

26 0x9798d23c in QQuickLabel::~QQuickLabel (this=0x6749e08, __in_chrg=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtbase/include/QtCore/../../src/corelib/global/qflags.h:122

27 0x9786ccc4 in QQmlPrivate::QQmlElement::~QQmlElement (this=0x6749e08, __in_chrg=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtdeclarative/include/QtQml/../../src/qml/qml/qqmlprivate.h:106

28 QQmlPrivate::QQmlElement::~QQmlElement (this=0x6749e08, __in_chrg=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtdeclarative/include/QtQml/../../src/qml/qml/qqmlprivate.h:108

29 0xaabd3338 in QObjectPrivate::deleteChildren (this=this@entry=0x7411ec8) at kernel/qobject.cpp:2019

30 0xaabd4908 in QObject::~QObject (this=, __in_chrg=) at kernel/qobject.cpp:1032

31 0xa7d07fa4 in QQuickItem::~QQuickItem (this=0x4846e18, __in_chrg=) at items/qquickitem.cpp:2443

32 0x979784d0 in QQuickControl::~QQuickControl (this=0x4846e18, __in_chrg=)

at ../../include/QtQuickTemplates2/5.13.0/QtQuickTemplates2/private/../../../../../src/quicktemplates2/qquickdeferredpointer_p_p.h:153

33 0x97953d18 in QQuickAbstractButton::~QQuickAbstractButton (this=0x4846e18, __in_chrg=) at qquickabstractbutton.cpp:458

34 0x97869cec in QQuickItemDelegate::~QQuickItemDelegate (this=0x4846e18, __in_chrg=)

35 QQmlPrivate::QQmlElement::~QQmlElement (this=0x4846e18, __in_chrg=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtdeclarative/include/QtQml/../../src/qml/qml/qqmlprivate.h:108

36 QQmlPrivate::QQmlElement::~QQmlElement (this=0x4846e18, __in_chrg=)

at /media/markb/Samsung/cura/cura-build-environment/build/Qt-prefix/src/Qt/qtdeclarative/include/QtQml/../../src/qml/qml/qqmlprivate.h:108

37 0xaabcbab8 in qDeleteInEventHandler (o=o@entry=0x4846e18) at kernel/qobject.cpp:4659

38 0xaabcf0bc in QObject::event (this=this@entry=0x4846e18, e=) at kernel/qobject.cpp:1251

39 0xa7d04538 in QQuickItem::event (this=0x4846e18, ev=0x5486a30) at items/qquickitem.cpp:8107

40 0x979558ec in QQuickAbstractButton::event (this=, event=) at qquickabstractbutton.cpp:1024

41 0xa96b7da8 in QApplicationPrivate::notify_helper (this=this@entry=0xbeffd92c, receiver=receiver@entry=0x4846e18, e=e@entry=0x5486a30) at kernel/qapplication.cpp:3740

42 0xa96c0e74 in QApplication::notify (this=0x17cf3d8, receiver=0x4846e18, e=0x5486a30) at kernel/qapplication.cpp:3096

43 0xa9ce5728 in ?? () from /media/markb/Samsung/cura/cura-build/build/package/usr/bin/lib/python3.5/PyQt5/QtWidgets.so

````

````

[fieldOfView]

Nope, does not ring a bell.

[nallath]

I think i actually made something that works like a pointed rectangle but then just using a rotated rectangle as the point.

[fieldOfView]

Keep in mind that you also need to be able to draw the border (which could be another rotated rectangle, but it needs to be drawn before the main rectangle)

[smartavionics]

Can't we just give it a material, if that's what it wants?

[smartavionics]

BTW, it seems that the initial crash (not the pointy rectangle crash) can be avoided if the shaders are commented out in qml/UM/RecolorImage.qml. OK, that makes all the icons come out as black squares but at least the app doesn't crash!

[fieldOfView]

Can't we just give it a material, if that's what it wants?

We already do: https://github.com/Ultimaker/Uranium/blob/master/UM/Qt/Bindings/PointingRectangle.py#L161

[smartavionics]

Hmm, so what I am now trying is to not use the shaders at all in RecolorImage but still display the image and this appears to work OK without crashing. So it now looks like this:
````
Item
{
id: base;

property alias source: img.source 
property color color: "#fff" 
property alias sourceSize: img.sourceSize 

Image 
{ 
    id: img 
    anchors.fill: parent 
    visible: true 
    sourceSize.width: parent.width 
    sourceSize.height: parent.height 
}

// ShaderEffect commented out
}
````
So could someone please tell me what the ShaderEffect was actually achieving and why just a simple image is not sufficient? Thanks.

[smartavionics]

I think I understand what ShaderEffect was being used for and I have substituted in ColorOverlay and so RecolorImage now looks like this:

import QtQuick 2.1 
import QtGraphicalEffects 1.12 
import UM 1.3 as UM 

Item 
{ 
    id: base; 

    property alias source: img.source 
    property alias color: overlay.color 
    property alias sourceSize: img.sourceSize 

    Image 
    { 
        id: img 
        anchors.fill: parent 
        visible: false 
        sourceSize.width: parent.width 
        sourceSize.height: parent.height 
    } 

    ColorOverlay { 
        id: overlay 
        anchors.fill: parent 
        source: img 
        color: "#fff" 
    }
} 

And here's a screenshot using the above qml and Qt 5.13 and PyQt 5.13 on Linux

[Ghostkeeper]

So could someone please tell me what the ShaderEffect was actually achieving and why just a simple image is not sufficient? Thanks.

The shader effect recolours an image into a colour of choice, keeping only the alpha channel. This is how we make our icons themeable and how we give the extruder icons and such the correct colour depending on the material.

[smartavionics]

I have now tested the above change to RecolorImage on both Linux and Windows using Qt 5.10 and both appear to work as normal. I can't build for OS X anymore so can't test that.

[smartavionics]

And just had confirmation that the above fixes allow Cura to run on Arch Linux again.

[protist]

I can also confirm that those two fixes fix Cura on Arch Linux. Thank you for the quick work!