Crash on newest AppImageKit used on Wi-Fi connection

[akontsevich]

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 ^^^

[azubieta]

**(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 ?

[akontsevich]

Could you share a non-working AppImage for analysis ?

Sorry no, proprietary and reproducible on drone connection by wi-fi.

[azubieta]

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.

[remster]

It may reproduce on QGC - but it will still involve connecting to a drone.

[TheAssassin]

This is likely not an appimagetool issue. Please move the discussion to appimagebuilder, or provide more information.

[probonopd]

@TheAssassin are you sure #1103 is not the cause?

[TheAssassin]

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.