AppImageLauncher
AppImageLauncher copied to clipboard
TheAssassin
[Settings] Crash on Debian stable (with non-Qt desktop)
Just been trying the settings dialog (installed via the bionic package) and there's some serious issues with the settings dialog:
That /path should not be shown there, it's a hidden default value because putting some value in there helps with Qt Designer. It's replaced during runtime.
It just froze after some time, so I had to kill the process. On a subsequent try, I could get a little further and hit the "choose path" button, which led to this state:
@azubieta, you're the Qt expert, any ideas? This is kinda bad...
There is not too much for us to do about the segfault . It's a qt5-gtk-platformtheme issue and it affects all qt5 applications. As workaround to the affected can update qt5-gtk-platformtheme or to uninstall it.
There are bug reports every where, related to qt 5.9 which is the one who comes by default on ubuntu bionic. https://bugzilla.redhat.com/show_bug.cgi?id=1392605 https://bugs.archlinux.org/task/57984
@azubieta thanks for looking into this.
Should we try to recognize that issue during runtime, and perhaps replace the dialog by a normal text field?
As far as I know this issue is only present on qt5-gtk-platformtheme builds using qt-5.9 therefore I don't think any workaround is required. Also it will be really hacky . We just have to leave the issue open for the people to find it when fall into it.
Well, in that case, there's really nothing we can do. Distros should really have fixed such critical issues right when they were discovered. This breaks half of the Qt apps I presume.
Any way to work around this issue? The window looks relatively simple, why not write it in Gtk in the first place? Leaving it to my distro to fix Qt isn't really satisfying, even if I know the issue is not on your side...
@darealshinji we're working on the issue already. Rewriting the application in Gtk+ isn't going to happen, that's double the work and we don't have any Gtk+ developers (also I don't like plain C; the first rule of C programming is, don't do C...).
@azubieta has some ideas how to resolve the issue. And in future Qt versions the issue has been resolved already it seems, at least if you check the bugtrackers.
Do you have a link to a bug report of this Qt issue? Maybe I could make a bug report in Ubuntu if there already isn't one.
@darealshinji @azubieta posted a few, see https://github.com/TheAssassin/AppImageLauncher/issues/218#issuecomment-516922329.
Here's the bug report I opened: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1838891
By the way does anyone know a way to disable the gtk3 plugin through an environment variable or something? Preloading a fake gtk3 library helps to force the qt file dialog to pop up:
echo "" | gcc -xc - -shared -fPIC -o libgtk-3.so.0 -Wl,-soname,libgtk-3.so.0 -s
LD_PRELOAD=./libgtk-3.so.0 AppImageLauncherSettings
Awesome trick. Today I discovered DontUseNativeDialog as an option to the QFileDialog. That might help. However, I don't think that will completely solve the problem. I'm going to build binaries though in a PR.
Someone on Launchpad wrote it might have to do with AppImageLauncher being linked statically against zlib instead of using the system library: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1838891/comments/3
Sounds plausible to me. Can you link a build against the systems zlib, re-enable native file chooser and see if that issue is still happening?
Interesting. Now, AppImageLauncher itself doesn't require a static zlib, libappimage has been linking to it statically all the time. IMO static linking is overrated, and zlib itself is actually on our blacklist of libraries to be bundled.
I'll reopen the issue and hopefully will get to testing the difference today. Thanks for the information.
@darealshinji it seems as of recently (#214) we're using the system libz. The latest release includes these changes already.
Can anyone test this who had a failure with the old builds please? Right now I'm already A/B testing (with an older and a newer build) to see if I can reproduce the crash.
It might be viable to re-test the Qt style plugins stuff then.
Confirming your findings in a xubuntu 19.04 VM with AppImageLauncher build 720. The exact same issue happens again with the latest (post-#214) build 783. It fails to read /usr/share/icons/elementary-xfce/status/16/image-missing.png. In that build we already link zlib dynamically.
I'm not entirely convinced this is AppImageLauncher's fault any more. This is with a system Qt installation, without any zlib artifacts left in the package.
The only possibility might be that AIL has been built on bionic, whereas this is 19.04.
I can confirm and reproduce the crash on Fedora 30 with GNOME 3.32.2 giving the following error message:
AppImageLauncherSettings: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
(AppImageLauncherSettings:15850): Gtk-WARNING **: 10:54:15.142: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/16x16/status/image-missing.png: Fatal error reading PNG image file: bad parameters to zlib (gdk-pixbuf-error-quark, 0)
Aborted (core dumped)
How have you installed AppImageLauncher and what version are you using, @skipperTux?
At the time of writing the above comment I had installed version 1.5.0 using the rpm package appimagelauncher-1.5.0-travis780.git20190816.cc1a7ad.x86_64.rpm with dnf.
Today I upgraded to version 2.0.0 (git commit 4075ba1) again using the rpm package, and I get the following error
AppImageLauncherSettings: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
(AppImageLauncherSettings:25286): Gtk-WARNING **: 17:57:31.668: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/16x16/status/image-missing.png: Fatal error reading PNG image file: bad parameters to zlib (gdk-pixbuf-error-quark, 0)
Aborted (core dumped)
It looks like the same error as in version 1.5.0.
This is a pretty strange situation... Let's continue to track this in #256.
On Debian stable (buster) under Gnome 3.30 (with KDE also installed), using AppImageLauncher 2.1.3 (bionic package) for the first time (First run dialog), the crash happens when pressing the "Customize" button (for choosing the integration target). Error message similar to those already reported:
$ ./digikam-6.4.0-x86-64_8e64071a63530d58f121cb1783ac6500.appimage
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[AppImageLauncher] Warning: can't find fallback icon for nameprocess-stop
(AppImageLauncher:4389): Gtk-WARNING **: 22:16:45.130: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/16x16/status/image-missing.png: Erreur fatale lors de la lecture du fichier d’image PNG : bad parameters to zlib (gdk-pixbuf-error-quark, 0)
Abandon
Only, I don't understand the previous discussion related to Qt 5.9 because I think Debian buster is shipping 5.11.
I am not entirely sure what exactly makes it behave that way, but it's definitely a broken Qt API. The only two realistic solutions are 1) ship all Qt libraries with our own packages (bloat!) or 2) produce binaries for all distros and variants (way too much work)...
Perhaps we need to set up some OBS repos at some point, and have that service build the app for all distros and variants, since they aren't limited to Ubuntu, for instance...
Not easy indeed. The workaround I found was to launch the First run dialog under KDE's plasma. Once the app integration is done, it works well under Gnome.
Not the best solution, but someone could try to write alternative GUIs in GTK+, FLTK or something similar for those who want them.
Same issue on Fedora 31 with appimagelauncher-2.1.4-travis987.7cb4d70.x86_64.rpm
Click on Customize -> crash.
Hi, Error still there on Debian Buster, with XFCE desktop:
/usr/bin/AppImageLauncherSettings
(process:32310): Gtk-WARNING **: 16:30:13.114: Locale not supported by C library.
Using the fallback 'C' locale.
[AppImageLauncher] Warning: can't find fallback icon for nameprocess-stop
(AppImageLauncherSettings:32310): Gtk-WARNING **: 16:30:35.790: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Tango/16x16/status/image-missing.png: Fatal error reading PNG image file: bad parameters to zlib (gdk-pixbuf-error-quark, 0)
No support without a version number. Also please provide screenshots.
Sorry.
Version is appimagelauncher_2.2.0-travis995.0f91801.bionic_amd64.deb
Screenshots: https://i.imgur.com/DlcBECR.png https://i.imgur.com/mUJzrbv.png
Le dim. 8 mai 2022 à 17:46, TheAssassin @.***> a écrit :
There is no crash in your screenshots.
Yes there is, in the second one, the error in in the terminal. The AIL window just crash/disappear when clicking on any button that opens the file selection panel.
I see. (I've edited my response right after posting it. You should use the website to respond.)