Application Version: Cura 2.7 - 3.0.3
Platform: Mac OS High Sierra and Sierra
Qt: n/a
PyQt: n/a
Display Driver: Intel HD Graphics 4000 1536 MB
Steps to Reproduce:
Attempting to input API key of OctoPrint
Actual Results:
Cura crashes and closes Immediately
Expected results:
The API key should have been written in the text box
Additional Information:
Can you add the full logs after the crash? Then we can see the culprit :)
It also helps to know if it happened just one time or if it is reproducable.
NB: I am the maintainer of the OctoPrintPlugin, also see https://github.com/fieldofview/OctoPrintPlugin
sure thing! here's the crash log (If you'd prefer a plaintext file I'll paste it, just didn't want to clutter up the thread)
cura_2017-10-18-153636_colin-3.crash.zip
The crash happens every single time any key is pressed while selecting the API key dialogue box with all versions of Cura after 2.6v
Unfortunately that's not a log that is very helpful to me. Can you share your cura.log? It is found in the Configuration Folder.
of course, here's the cura.log file.
cura.log
One more request... The application crashes in a way that is not logged in the normal Cura.log. There are two files that may have some more info:
~/Library/Logs/cura/stderr.log
~/Library/Logs/cura/stdout.log
Please make cura crash, and then get those files (they get overwritten when you restart Cura).
Here's the first file, I was unable to upload stdout.log as it was empty, Is this a problem? I can re-crash Cura and try again if that would help?
Thanks, that is helpful. The stdout.log being empty is also good to know.
The stderr.log shows me where the error happens, but not yet what to do about it. I will see if I can get the issue reproduced.
This seems to have the same crash mechanism as https://github.com/Ultimaker/Cura/issues/2617. The crash happens when using QNetworkAccessManager to get() a QNetworkRequest.
The OctoPrint plugin uses very similar code to the UM3 network printing plugin because the OctoPrint plugin started out as a fork of the UM3 network printing plugin.
Thanks for taking a look at it!
I just reset my system totally and tried it. It doesn't crash but just sticks on checking the API key forever, it also does this on my friends mac (newer model)
I'll see if it has the issue when booting into windows.
It works! just really really really slow to connect.
Just for information, I have the same issue happening on 2.7 and 3.
Note that #2617, which I am convinced is the same underlying issue, was just closed because noone can reproduce the issue.
Seems like I'm experiencing the same issue as Erin-Cooper, but on Linux.
Using Cura-3.0.4.AppImage. Running Fedora 26 on two machines (one on KDE, the other Gnome) when I attempt to enter API Key. As soon as any character is entered into the API Key field, I see all the lines that begin with qt.network.ssl: messaged in the cura-console.log file.
I have never ran Cura on either workstation. I run the AppImage from command line. On first run I accept the agreement, then added Creality CR-10 as printer. Then enter Preferences > Configure Cura > Printers. Select CR-10, then click Connect OctoPrint. Select octopi._octoprint._tcp.local.
I get the same output on the console on both systems. I have tried manually adding the OctoPrint instance both by name and IP, and HTTP/HTTPS. Same results either way
@awhiemstra, could it be that there鈥檚 some ssl bits that have not been packaged well?
I'm having the exact same problem as @Erin-Cooper. Sierra 10.12.6. I removed the app and all the settings and started over without setting up anything. Still the same issue. Works fine on Windows but not my Mac.
cura.log
stderr.log
stdout.log is empty
Try disabling any System proxy configuration that you can. I just commented on #2617 with a way to reproduce on and off.
@kkalbaugh, @Erin-Cooper, could you confirm you are using a proxy?
I am not using a proxy. Just a small home network.
Bummer, nothing else out of the ordinary in terms of network setup or possible interference such as McAfee, ZScaler, etc? I was getting this exact crash error until I disabled my system Proxy Auto Configuration/PAC file.
@fieldOfView Would you like me to open a separate issue besides #2617 detailing the proxy issue?
Let鈥檚 wait it out a little. There are so many issues already.
I have the same issue on a clean install of Cura 3.1 on Windows 10. As soon as I just want to type one character of the API key Cura crashes. It happens all the time, there is no chance to get Octoprint work with Cura right now.
I can confirm: I am using Automatic Proxy Configuration. With PAC turned on, Cura crashes when I try to connect to Octoprint (i.e. enter API key). With PAC turned off, it works just fine. Even if I disable PAC, enter the API key and connect to Octoprint, it immediately crashes when I re-activate PAC. This applies to Cura 2.7, 3.0.4 and 3.1 on OSX (HighSierre 10.13.2). So there definitely is a Proxy issue.
I don't have a proxy as far as I know. And I get a crash as soon as I try to enter the first character. This is on the AppImage.
@tigert, that is new information. Sofar this has been identified as an OSX High Sierra issue. What OS are you on?
@fieldOfView I concur with @schneehorn's observation. I'm able to replicate on OSX High Sierra, works fine until I enable Automatic Proxy Discovery. Cura crashes on start. Disable PAC and Cura runs fine.
On my Fedora 26 machine using the appimage, Cura crashes immediately when typing any character in the API key field. I have no proxy configured on my Fedora machines. Auto Discovery is off. I run Cura from the command line and get all those qt.network.ssl: QSslSocket: cannot resolve... on the console right after pressing the key, then crash.
I ran Cura from the terminal on OSX, and I did not see those qt.network.ssl messages there, nor in the Apple crash reporting tool, when it crashes. I guess the OSX executable works a little different than the Linux appimage in that respect.The only thing on the console is Segmentation fault: 11
Attached is the info from the Apple Crash reporter
OSX HS Cura crash.txt
The OSX issue is a QTNetwork issue as I suggested in #2617, I would bet that the linux issue is as well. Maybe this one https://bugreports.qt.io/browse/QTCREATORBUG-18137? Probably not picking up OpenSSL or the wrong version.
If it is that Qtnetwork bug, then setting LD_LIBRARY_PATH=/usr/lib/openssl-1.0/ with the call of Cura could be a workaround? And upgrading to Qt 5.9 could fix the bug for real. I understand that such an upgrade (to 5.10) could be planned for the 3.3 release.
I can reproduce the crash on Windows 10 (Cura 3.1, 3.2). Additionally cura crashes, when saving a sliced file, when "Send (anonymous) print information" is enabled. I would be glad to help!
We haven't included Qt 5.9 or 5.10 yet in version 3.2, so that's expected. For the crash please create a new ticket so we can track issues properly. We probably also received the crash report already then.
I created a new issue - but: If it is a qt problem - if i install the Qt libraries, how do i tell cura to use them? Something like "QT_LIBRARY_PATH="?
I think you need QT_PLUGIN_PATH. See an example here of some things you could try: https://github.com/Ultimaker/cura-build/blob/0e0d4623ca377be3f7e86b714032d9b8e13c7dfd/packaging/cura.sh#L7
Duplicate of https://github.com/Ultimaker/Cura/issues/2617.
Hi all, we have created a 3.4 BETA build for mac with Qt 5.10 hoping it can fix this issue. Could you try it out see if problem still exists? Thank you all!
Download link: https://we.tl/43i1hChi8m
In case the link expires, let us know so we can upload a new one.
Sorry guys... I only uploaded the linux AppImage, this is the link which contains all installers/AppImage/DMG.
https://we.tl/MLmTYeGuW5