AppImage
Crash on newest AppImageKit used on Wi-Fi connection
We use appimage-builder in docker to build AppImages and build them like this: Install appimagetool. However our qgroundcontrol become to crash on Wi-Fi connection after 31 of Dec for some reason. Now we just downgraded appimagetool to 12th version and all works fine:
- RUN wget https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage -O /opt/appimagetool \
+ RUN wget https://github.com/AppImage/AppImageKit/releases/download/12/appimagetool-x86_64.AppImage -O /opt/appimagetool \
The last thing the AppImage says before crashing:
**(app:3456): GLib-GIO-ERROR : No GSettings schemas are installed on the system
Please fix if you have any idea why it could crash. @azubieta FYI ^^^
**(app:3456): GLib-GIO-ERROR : No GSettings schemas are installed on the system
This is a common error that doesn't cause a crash. We would have to investigate the latest changes in appimagetool.
Could you share a non-working AppImage for analysis ?
Could you share a non-working AppImage for analysis ?
Sorry no, proprietary and reproducible on drone connection by wi-fi.
Ok, I'm not up to date with the latest changes on appimagetool let's wait for @probonopd and @TheAssassin to give us some hints on where to look for a possible bug.
This is likely not an appimagetool issue. Please move the discussion to appimagebuilder, or provide more information.
@TheAssassin are you sure https://github.com/AppImage/AppImageKit/pull/1103 is not the cause?
With the little bit of information I was confident enough. The tiny log bit they provided don't give me any reason to suspect #1103. I don't like it when people don't provide a full (censored) log of what they're doing.
In theory, GSETTINGS_SCHEMA_DIR could be set in their environment. But, then again, they need to provide more information. This would be a very non-typical deployment.
Plus, I've long ago advocated for using linuxdeploy to deploy appimagetool. This would eliminate the need for crude hacks like #1103. This entire AppRun.c must go away. This year alone I had to instruct about 20 (!) AppImage creators to not use it, because it breaks everything. It's a really, really, really bad hack, and the only reason #1103 was necessary at all.
If you insist on AppRun.c, then someone has to basically replace #1103 with a solution that just removes the leading entry from the environment variables listed in there. But, really, who would prefer such a solution?
KDE for instance also have a workaround for AppRun.c that is preloading a lib that does the env cleaning. But, again, a bad hack to work around an even worse hack.