probonopd
commented
5 years ago Moving AppImageAssistant away makes it segfault on another AppImage.
Closed probonopd closed 5 years ago
probonopd
commented
5 years ago Moving AppImageAssistant away makes it segfault on another AppImage.
probonopd
commented
5 years ago This can be reproduced, even after a reboot. It happens since I had updated AILL a couple of days ago. It was not an issue e.g., in this version:
me@host:~$ /home/me/.local/lib/appimagelauncher-lite/appimagelauncher-lite.AppImage cli --version
ail-cli version 1.3.1 (git commit b9b466a), built on 2019-07-04 00:23:30 UTCdmesg is interesting:
[ 5134.602499] Thread (pooled)[19796]: segfault at 5c03a000 ip 00007fb76fdb40f0 sp 00007fb763ad1050 error 4 in libappimage.so.0[7fb76fda1000+5d000]
[ 5134.602505] Code: 00 31 c0 4c 89 ff e8 6f b3 ff ff 48 98 48 85 c0 48 89 44 24 70 0f 84 1f 01 00 00 48 8d 3d 0c 3f 03 00 48 89 c6 b9 05 00 00 00 <f3> a6 48 8d 3d 01 3f 03 00 48 89 c6 b9 05 00 00 00 40 0f 97 c5 0f
[ 5145.061895] Thread (pooled)[19807]: segfault at ffffffff8c00f780 ip 00007eff9cebb0f0 sp 00007eff90bd8050 error 5 in libappimage.so.0[7eff9cea8000+5d000]
[ 5145.061902] Code: 00 31 c0 4c 89 ff e8 6f b3 ff ff 48 98 48 85 c0 48 89 44 24 70 0f 84 1f 01 00 00 48 8d 3d 0c 3f 03 00 48 89 c6 b9 05 00 00 00 <f3> a6 48 8d 3d 01 3f 03 00 48 89 c6 b9 05 00 00 00 40 0f 97 c5 0f
[ 5155.563161] Thread (pooled)[19819]: segfault at ffffffff94011550 ip 00007f7ead3f10f0 sp 00007f7ea110e050 error 5 in libappimage.so.0[7f7ead3de000+5d000]
[ 5155.563167] Code: 00 31 c0 4c 89 ff e8 6f b3 ff ff 48 98 48 85 c0 48 89 44 24 70 0f 84 1f 01 00 00 48 8d 3d 0c 3f 03 00 48 89 c6 b9 05 00 00 00 <f3> a6 48 8d 3d 01 3f 03 00 48 89 c6 b9 05 00 00 00 40 0f 97 c5 0f Repeated maaaaaaany times.
TheAssassin
commented
5 years ago @azubieta any ideas?
probonopd
commented
5 years ago Any progress? All other work should imho stop until this is fixed.
probonopd
commented
5 years ago 
azubieta
commented
5 years ago I had a similar issue with AppImageServices and AppImageLauncher. It seems it that the latter interfering in a bad way. Sorry for taking so long to answer had an issue with my system and had to do a full reinstall + recovering my all my keys.
Will start working on this right away.
azubieta
commented
5 years ago Tracked down the issue to libappimage. It seems that the bug is no longer present on newer versions please try this build which uses libappimage v1.0.2
probonopd
commented
5 years ago Thank @azubieta. @TheAssassin can you please make that version show up under https://github.com/TheAssassin/AppImageLauncher/releases/tag/continuous, as that is what I am testing. My tools are not set up to pull "random" other builds. (If we had a Monorepo, @azubieta's changes in libappimage would automatically have triggered a build of everything, including AILL...)
azubieta
commented
5 years ago Already sent a PR, it's @TheAssassin call to do the merges as he is the project owner :)
(If we had a Monorepo, @azubieta's changes in libappimage would automatically have triggered a build of everything, including AILL...
Or a continuous integration infrastructure for all the projects
probonopd
commented
5 years ago Or a continuous integration infrastructure for all the projects
Yes, that would however either require us to set up private infrastructure or to use something like the Open Build Service (possibly GitLab CI and/or Azure Pipelines could do it, too).
TheAssassin
commented
5 years ago @probonopd can you please generate a stacktrace and provide it here? All binaries built on Travis contain debug symbols for good reasons. I have serious doubts the issue is a plain libappimage one, since things worked before merging #207. That doesn't mean it's responsible, but I'd like to know for sure.
TheAssassin
commented
5 years ago So the issue is indeed in libappimage. I have serious doubts the whole thing worked with the old version, and I don't see any evidence for this from @probonopd, looks more like an assumption.
Considering this to be solvable by #214.
probonopd
commented
5 years ago I have serious doubts the whole thing worked with the old version, and I don't see any evidence for this from @probonopd, looks more like an assumption.
Luckily I am keeping around old versions, so I can verify that it ẁas working with
me@host:~$ .local/lib/appimagelauncher-lite/appimagelauncher-lite.AppImage cli --version
ail-cli version 1.3.1 (git commit b9b466a), built on 2019-07-04 00:23:30 UTCProbably because that one bundled another liappimage version. I am not saying that the fault lies within code from this repository, all I am saying is that the AILL AppImage that is being currently distributed by this repository is currently broken.
TheAssassin
commented
5 years ago @azubieta @probonopd please explain to me then why it used to work before your changes with regards to auto restarting. I don't see any changes in the version of libappimage that was used. See the paradox? That doesn't make any sense.
TheAssassin
commented
5 years ago Probably because that one bundled another liappimage version. I am not saying that the fault lies within code from this repository, all I am saying is that the AILL AppImage that is being currently distributed by this repository is currently broken.
Might be, but still; I don't see any relation there. I see the new version is not working, I haven't got to testing an older one. You're both just guessing in the wild, but I'd like to see a real explanation. I mean, it can't be that hard.
probonopd
commented
5 years ago When I say "it was working" I did not mean "it was doing the auto-restarting cleverly", I merely meant to say "it did not crash and hence it did not run into this sort of problem."
probonopd
commented
5 years ago You're both just guessing in the wild, but I'd like to see a real explanation. I mean, it can't be that hard.
Please let me know what I can do/test to clarify things. For me it is simple, b9b466a was working for me whereas the current master is broken.
TheAssassin
commented
5 years ago The only difference I can spot is that AIL Lite used to be built on bionic accidentally. Maybe that's the key difference here?
probonopd
commented
5 years ago That would of course explain it
azubieta
commented
5 years ago Here is why I blame libappimage for the issue, many factors may influence the crash but in the end is an error on libappimage. If I remember properly we had a similar error on early versions appimaged.
Integrating: /home/alexis/Applications/QTalarm-8028f64-x86_64.AppImage
Integrating: /home/alexis/Applications/SocNetV-2.6-dev-93df74c-x86_64.AppImage
Integrating: /home/alexis/Applications/KeePassXC-2.4.3-x86_64.AppImage
Integrating: /home/alexis/Applications/Installar_Mapeo_v4.0.3-beta_linux.AppImage
This doesn't look like a squashfs image.
This doesn't look like a squashfs image.
WARNING: AppImage shall not be integrated, skipping
WARNING: AppImage shall not be integrated, skipping
Thread 2 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8908700 (LWP 17694)]
0x00007ffff6f240f0 in desktop_integration_modify_desktop_file () from /home/alexis/Downloads/squashfs-root/usr/bin/../lib/libappimage.so.0
(gdb) bt
#0 0x00007ffff6f240f0 in desktop_integration_modify_desktop_file () at /home/alexis/Downloads/squashfs-root/usr/bin/../lib/libappimage.so.0
#1 0x00007ffff6f22de5 in appimage_register_in_system () at /home/alexis/Downloads/squashfs-root/usr/bin/../lib/libappimage.so.0
#2 0x00000000004117fc in installDesktopFileAndIcons(QString const&, bool) (pathToAppImage=..., resolveCollisions=resolveCollisions@entry=true) at /ws/src/shared/shared.cpp:335
#3 0x000000000040ba3d in Worker::PrivateData::OperationTask::run() (this=0x66a850) at /ws/src/daemon/worker.cpp:75
#4 0x00007ffff688a2d3 in () at /home/alexis/Downloads/squashfs-root/usr/bin/../lib/libQt5Core.so.5
#5 0x00007ffff688d7be in () at /home/alexis/Downloads/squashfs-root/usr/bin/../lib/libQt5Core.so.5
#6 0x00007ffff6cf96db in start_thread (arg=0x7fffe8908700) at pthread_create.c:463
#7 0x00007ffff5f7788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
You have all the breaking AppImages (they're not necessarily broken, but they trigger the segfault), so could you please try the builds right before and after that change? That might be https://artifacts.assassinate-you.net/artifactory/AppImageLauncher/travis-679/appimagelauncher-lite-1.3.1-x86_64.AppImage vs. https://artifacts.assassinate-you.net/artifactory/AppImageLauncher/travis-683/appimagelauncher-lite-1.3.1-x86_64.AppImage.
azubieta
commented
5 years ago azubieta
commented
5 years ago Actually I cannot reproduce the error if I build the project locally. Only the Travis build causes the crash. Which leads me to suspect that something on our build environment also changed.
I did an small experiment, extracted the version that fails and replaced the libappimage binary by the one in the version that works (I'm using the links provided by @TheAssassin above) and the resulting project works. Therefore the error is in libappimage.
TheAssassin
commented
5 years ago @azubieta there is no doubt any more the issue is in the libappimage binary. I'll be building the Lite version on bionic again until we move on to merging #214 and therefore going for 2.x.
TheAssassin
commented
5 years ago Segfaults are gone since #217, giving up on compat with xenial (which is okay, since the Lite is still alpha and will become beta in the next release; we'll restore oldest-LTS compat when we are ready to upgrade libappimage).
probonopd
commented
5 years ago Segfaults are gone since #217
Thanks for the workaround, I can confirm that they are gone on xubuntu-18.04-desktop-amd64.iso.
Apparently the current workaround is to build on bionic. What is the reason that this makes a difference? Is is because AILL and/or appimaged are using "modern C++" that result in this kind of trouble in all but the latest-and-greatest systems? I would like to understand the reason.
giving up on compat with xenial (which is okay, since the Lite is still alpha and will become beta in the next release; we'll restore oldest-LTS compat when we are ready to upgrade libappimage).
Generally, we recommend 3rd party projects to use the oldest still-supported LTS as the platform to develop against, why does libappimage not follow that advice=
Using
xubuntu-18.04-desktop-amd64.iso: