linuxdeploy
linuxdeploy copied to clipboard
linuxdeploy
linuxdeploy crashes on Ubuntu Xenial running with docker
Hi,
I have a git project set up to automatically build an AppImage of my project once a day, however, since August 6 (for a while now already, haven't had time to look into it until now) linuxdeploy crashes when run in a docker image of Ubuntu Xenial.
Here's the series of commands I use leading up to the final crash:
# ./linuxdeploy-plugin-qt-x86_64.AppImage --appimage-extract
# ./linuxdeploy-x86_64.AppImage --appimage-extract
# QML_SOURCES_PATHS=./qml ./squashfs-root/AppRun --appdir ./appdir/ -d ./appdir/usr/share/applications/myapp.desktop --plugin=qt --output appimage
linuxdeploy version 1-alpha (git commit ID b6a1ba2), Travis build 488 built on 2020-10-09 13:07:48 UTC
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 1)
Aborted (core dumped)
Here's the verbose output I get with the -v0 switch:
debug.txt
Am I missing anything/doing anything wrong, or is this a bug?
If I use an old AppImage from right before when this started (downloaded from here, found this link in another issue: https://artifacts.assassinate-you.net/artifactory/list/linuxdeploy/travis-456/) everything still works, so something got added/changed after August 5th that makes my sequence of commands fail.
I could imagine that this was due to issues in the new subprocess library, which have been fixed already. Please retry with the latest continuous build.
I just tried it with the latest continuous build and it still fails with the same error.
Sure, no problem:
$ QML_SOURCES_PATHS=./qml ./squashfs-root/AppRun --appdir ./appdir/ -d ./appdir/usr/share/applications/myapplication.desktop --plugin=qt --output appimage -v0
linuxdeploy version 1-alpha (git commit ID 3e05627), Travis build 490 built on 2020-11-18 18:21:58 UTC
DEBUG: Searching for plugins in directory /builds/project-0/squashfs-root/usr/bin
DEBUG: Doesn't match plugin regex, skipping: /builds/project-0/squashfs-root/usr/bin/strip
DEBUG: Doesn't match plugin regex, skipping: /builds/project-0/squashfs-root/usr/bin/linuxdeploy
DEBUG: Found plugin 'appimage': /builds/project-0/squashfs-root/usr/bin/linuxdeploy-plugin-appimage
DEBUG: Doesn't match plugin regex, skipping: /builds/project-0/squashfs-root/usr/bin/patchelf
DEBUG: Found plugin 'qt': /builds/project-0/squashfs-root/usr/bin/linuxdeploy-plugin-qt
DEBUG: Searching for plugins in directory /opt/qt59/bin
DEBUG: Doesn't match plugin regex, skipping: /opt/qt59/bin/qmake
[... many lines like the one right above/below ...]
DEBUG: Doesn't match plugin regex, skipping: /bin/bzip2
DEBUG: Searching for plugins in directory /builds/project-0
DEBUG: Doesn't match plugin regex, skipping: /builds/project-0/linuxdeploy-x86_64.AppImage
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 1)
/bin/bash: line 92: 8841 Aborted (core dumped) QML_SOURCES_PATHS=./qml ./squashfs-root/AppRun --appdir ./appdir/ -d ./appdir/usr/share/applications/myapplication.desktop --plugin=qt --output appimage -v0
ERROR: Job failed: exit code 1
FATAL: exit code 1
Okay. Weird. I don't see any obvious issue with this. IIRC the AppImages contain debug binaries. Mind to attach one to your call and see if you can get a stacktrace? (env ... gdb ./squashfs-root/AppRun --appdir ...)
Unfortunately there doesn't seem to be any debug info available:
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 1)
Program received signal SIGABRT, Aborted.
0x00000000005b3457 in ?? ()
(gdb) bt
#0 0x00000000005b3457 in ?? ()
#1 0x00000000005b3651 in ?? ()
#2 0x0000000000593f05 in ?? ()
#3 0x00000000004faf46 in ?? ()
#4 0x00000000004faf91 in ?? ()
#5 0x00000000004f8fc4 in ?? ()
#6 0x00000000004f60af in ?? ()
#7 0x000000000047114e in ?? ()
#8 0x0000000000470c89 in ?? ()
#9 0x0000000000467753 in ?? ()
#10 0x0000000000468544 in ?? ()
#11 0x0000000000401d87 in ?? ()
#12 0x00000000005a2f69 in ?? ()
#13 0x000000000040695a in ?? ()
That is quite odd. I just checked the scripts again, and it's built with -DCMAKE_BUILD_TYPE=RelWithDebInfo, which means, include symbols but turn on optimizations.
Does linuxdeploy work without all these options? Can you reproduce the issue without any parameter or environment variable?
Hm, that is indeed odd.
Even if I run it without any options (i.e., simply ./squashfs-root/AppRun) it gives the same crash...
If I do the same steps in an Ubuntu bionic docker container I get the exact same error.
Hi all,
I have the same problem and I built a debug version of linuxdeploy. The exception is thrown here:
#0 0x00007ffff71634f5 in raise () from /lib64/libc.so.6
#1 0x00007ffff7164cd5 in abort () from /lib64/libc.so.6
#2 0x0000555555573fc1 in __gnu_cxx::__verbose_terminate_handler () at /tmp/gcc-10.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x000055555566bae6 in __cxxabiv1::__terminate(void (*)()) (handler=Unhandled dwarf expression opcode 0xf3
) at /tmp/gcc-10.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:48
#4 0x000055555566bb51 in std::terminate() () at /tmp/gcc-10.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:58
#5 0x000055555566bca4 in __cxa_throw () at /tmp/gcc-10.2.0/libstdc++-v3/libsupc++/eh_throw.cc:95
#6 0x0000555555665d5c in _ZNK11linuxdeploy10subprocess10subprocess12check_outputB5cxx11Ev () at /tmp/linuxdeploy/src/subprocess/subprocess.cpp:85
#7 0x00005555556070a2 in linuxdeploy::plugin::base::PluginBase<0>::PrivateData::getApiLevelFromExecutable() () at /tmp/linuxdeploy/include/linuxdeploy/plugin/base_impl.h:55
#8 0x0000555555606da6 in linuxdeploy::plugin::base::PluginBase<0>::PrivateData::PrivateData(boost::filesystem::path const&) () at /tmp/linuxdeploy/include/linuxdeploy/plugin/base_impl.h:42
#9 0x0000555555606af3 in linuxdeploy::plugin::base::PluginBase<0>::PluginBase(boost::filesystem::path const&) () at /tmp/linuxdeploy/include/linuxdeploy/plugin/base_impl.h:96
#10 0x000055555560618f in linuxdeploy::plugin::Type0Plugin::Type0Plugin(boost::filesystem::path const&) () at /tmp/linuxdeploy/src/plugin/plugin_type0.cpp:23
#11 0x0000555555601ab0 in linuxdeploy::plugin::createPluginInstance(boost::filesystem::path const&) () at /tmp/linuxdeploy/src/plugin/plugin.cpp:30
#12 0x00005555556023b4 in _ZN11linuxdeploy6plugin11findPluginsB5cxx11Ev () at /tmp/linuxdeploy/src/plugin/plugin.cpp:95
#13 0x00005555555788f9 in main () at /tmp/linuxdeploy/src/main.cpp:93
Extended logs for plugin loading gives the following output:
linuxdeploy version 1-alpha (git commit ID 3e05627), bbbbbb built on aaaaa
DEBUG: Searching for plugins in directory /tmp/linuxdeploy-build/bin
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/linuxdeploy
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/plugin_test
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/appdir_test
DEBUG: Searching for plugins in directory /usr/local/sbin
DEBUG: Searching for plugins in directory /usr/local/bin
DEBUG: Found plugin 'appimage': /usr/local/bin/linuxdeploy-plugin-appimage
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 1)
Aborted (core dumped)
Removing the existing appimage plugin in /usr/local/bin/linuxdeploy-plugin-appimage results in the same exception:
linuxdeploy version 1-alpha (git commit ID 3e05627), bbbbbb built on aaaaa
DEBUG: Searching for plugins in directory /tmp/linuxdeploy-build/bin
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/linuxdeploy
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/plugin_test
DEBUG: Doesn't match plugin regex, skipping: /tmp/linuxdeploy-build/bin/appdir_test
DEBUG: Searching for plugins in directory /usr/local/sbin
DEBUG: Searching for plugins in directory /usr/local/bin
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 1)
Aborted (core dumped)
I hope this helps you to solve the issue.
As expected, it crashes for some reason while probing a plugin. I wonder why you had put linuxdeploy-plugin-appimage in /usr/local/bin, though...
Can you perhaps step into createPluginInstance and see what path exactly it tries to probe there?
Once you have the path, please call it with --plugin-api-version and provide the output.
This in a docker image only used for building AppImages and it's in /usr/local/bin because this directory is in the PATH environment variable.
The problem is /usr/local/bin/linuxdeploy-plugin-qt:
$ /usr/local/bin/linuxdeploy-plugin-qt --plugin-api-version
/usr/local/bin/linuxdeploy-plugin-qt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/bin/linuxdeploy-plugin-qt)
/usr/local/bin/linuxdeploy-plugin-qt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/linuxdeploy-plugin-qt/usr/bin/../lib/libpng15.so.15)
/usr/local/bin/linuxdeploy-plugin-qt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/linuxdeploy-plugin-qt/usr/bin/../lib/libjpeg.so.62)
$ /lib64/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-23).
Compiled on a Linux 2.6.32 system on 2019-04-09.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
Yes, we are still on Red Hat 6. As it's been EOL from 30. Nov. 2020 on, we will now switch to Red Hat 7.
I am affected by the exactly same bug now: https://github.com/AppImage/AppImageUpdate/runs/1523620713?check_suite_focus=true#step:3:3965
What's good about this is it gives me the chance to debug it myself.
So, it looks like this has nothing to do with linuxdeploy (other than linuxdeploy not being that helpful with showing no error message), but it's the Qt plugin that crashes as-is, due to some issue:
# ./linuxdeploy-plugin-qt-i386.AppImage
sqfs_read_range error: File exists
*** Error in `./linuxdeploy-plugin-qt-i386.AppImage': double free or corruption (!prev): 0x083ac638 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x67387)[0xf7def387]
/lib/i386-linux-gnu/libc.so.6(+0x6d307)[0xf7df5307]
/lib/i386-linux-gnu/libc.so.6(+0x6dc41)[0xf7df5c41]
/lib/i386-linux-gnu/libc.so.6(fclose+0x177)[0xf7de5b67]
./linuxdeploy-plugin-qt-i386.AppImage(extract_appimage+0x4dd)[0x804c511]
./linuxdeploy-plugin-qt-i386.AppImage(main+0x3ed)[0x804cb32]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xf7da0647]
./linuxdeploy-plugin-qt-i386.AppImage[0x804b891]
======= Memory map: ========
[...]
This was run in an Ubuntu xenial VM. I had to patch out the magic bytes in order to make it run at all. I guess that breaks the AppImage. I'll keep digging.
I was able to fix the issue by not using sed to patch out the magic bytes but the much more precise and determinstic dd:
> dd if=/dev/zero of=linuxdeploy-plugin-qt-i386.AppImage conv=notrunc bs=1 count=3 seek=8
This fixes the issue in my MWE. I will try it in a larger build script ASAP.
Edit: I tested this in an i386/ubuntu:xenial container, on a system where the magic bytes prevent the AppImage from running in Docker. I had exported APPIMAGE_EXTRACT_AND_RUN=1.
Fixed for AppImageUpdate. This brings up two questions:
- Is linuxdeploy crashing because the Qt plugin process crashes? (That's a minor bug in linuxdeploy then)
- Do you patch out the magic bytes using the
sedmethod, which apparently cripples the Qt plugin AppImage?
Thanks for looking into it @TheAssassin !
I don't know if that adds potential confusion again: If I build an AppImage today using a build of linuxdeploy from back in August and the latest Qt plugin, then everything works just fine. If the problem is indeed in the plugin (as it appears to based on your analysis) then it at least didn't affect anything before some change in linuxdeploy in late August...
You missed to answer either question. Have you actually tried running the Qt plugin? Do you patch out the magic bytes?
Sorry, here we go:
Running the plugin in a docker contaner running ubuntu xenial works just fine:
# ./squashfs-root/usr/bin/linuxdeploy-plugin-qt --plugin-api-version
0
Patching out the magic bytes using the dd command you posted above doesn't change anything.
If I remove the qt plugin then linuxdeploy starts out just fine doing a bunch of stuff until it eventually expectedly fails with ERROR: Could not find plugin: qt.
If I copy the qt plugin appimage back (even without extracting it, just having the plugin appimage present) then I get the original error message right away when I try to run linuxdeploy.
So it must be some issue in the subprocess stuff. But as we can't see the error message behind the logic_error, we can just guess, I guess (no pun intended).
Perhaps I can reproduce your environment. What is your Docker version and what's the OS it's running on?
Locally I am running Arch Linux. I run Ubuntu:Xenial in docker.
$ docker --version
Docker version 19.03.14-ce, build 5eb3275d40
I also get the error when running a job using GitLab's CI. I'm not sure what their underlying OS is.
Edit: If it helps, this is the .gitlab-ci.yml file that sets up the environment/etc. for building the AppImage. Right now it retrieves an August build of linuxdeploy in line 52.
From: https://github.com/linuxdeploy/linuxdeploy-plugin-qt/issues/81
I'm running the latest Continuous build on Ubuntu 16.04 docker container. Here is the github action log: https://github.com/abcfy2/qBittorrent-Enhanced-Edition/runs/1546180473?check_suite_focus=true
And here is the terminal output:
linuxdeploy version 1-alpha (git commit ID 58f8b6a), <local dev build> built on 2020-12-11 11:11:24 UTC
*** Error in `/tmp/linuxdeploy-plugin-qt-x86_64.AppImage': double free or corruption (top): 0x0000000002359ad0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7fc750f3f7f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8038a)[0x7fc750f4838a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fc750f4c58c]
/lib/x86_64-linux-gnu/libc.so.6(fclose+0x103)[0x7fc750f35373]
/tmp/linuxdeploy-plugin-qt-x86_64.AppImage(extract_appimage+0x47c)[0x405298]
/tmp/linuxdeploy-plugin-qt-x86_64.AppImage(main+0x3b7)[0x405855]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fc750ee8840]
/tmp/linuxdeploy-plugin-qt-x86_64.AppImage[0x4046b9]
======= Memory map: ========
00400000-0042b000 r-xp 00000000 103:05 334042 /tmp/linuxdeploy-plugin-qt-x86_64.AppImage
0062a000-0062b000 rw-p 0002a000 103:05 334042 /tmp/linuxdeploy-plugin-qt-x86_64.AppImage
02354000-0237b000 rw-p 00000000 00:00 0 [heap]
7fc74c000000-7fc74c021000 rw-p 00000000 00:00 0
7fc74c021000-7fc750000000 ---p 00000000 00:00 0
7fc750cb2000-7fc750cc8000 r-xp 00000000 103:05 332345 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc750cc8000-7fc750ec7000 ---p 00016000 103:05 332345 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc750ec7000-7fc750ec8000 rw-p 00015000 103:05 332345 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc750ec8000-7fc751088000 r-xp 00000000 103:05 332402 /lib/x86_64-linux-gnu/libc-2.23.so
7fc751088000-7fc751288000 ---p 001c0000 103:05 332402 /lib/x86_64-linux-gnu/libc-2.23.so
7fc751288000-7fc75128c000 r--p 001c0000 103:05 332402 /lib/x86_64-linux-gnu/libc-2.23.so
7fc75128c000-7fc75128e000 rw-p 001c4000 103:05 332402 /lib/x86_64-linux-gnu/libc-2.23.so
7fc75128e000-7fc751292000 rw-p 00000000 00:00 0
7fc751292000-7fc7512ad000 r-xp 00000000 103:05 45201 /lib/x86_64-linux-gnu/libz.so.1.2.11
7fc7512ad000-7fc7514ac000 ---p 0001b000 103:05 45201 /lib/x86_64-linux-gnu/libz.so.1.2.11
7fc7514ac000-7fc7514ad000 r--p 0001a000 103:05 45201 /lib/x86_64-linux-gnu/libz.so.1.2.11
7fc7514ad000-7fc7514ae000 rw-p 0001b000 103:05 45201 /lib/x86_64-linux-gnu/libz.so.1.2.11
7fc7514ae000-7fc7514c6000 r-xp 00000000 103:05 332568 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fc7514c6000-7fc7516c5000 ---p 00018000 103:05 332568 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fc7516c5000-7fc7516c6000 r--p 00017000 103:05 332568 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fc7516c6000-7fc7516c7000 rw-p 00018000 103:05 332568 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fc7516c7000-7fc7516cb000 rw-p 00000000 00:00 0
7fc7516cb000-7fc7516ce000 r-xp 00000000 103:05 2765556 /lib/x86_64-linux-gnu/libdl-2.23.so
7fc7516ce000-7fc7518cd000 ---p 00003000 103:05 2765556 /lib/x86_64-linux-gnu/libdl-2.23.so
7fc7518cd000-7fc7518ce000 r--p 00002000 103:05 2765556 /lib/x86_64-linux-gnu/libdl-2.23.so
7fc7518ce000-7fc7518cf000 rw-p 00003000 103:05 2765556 /lib/x86_64-linux-gnu/libdl-2.23.so
7fc7518cf000-7fc7518f5000 r-xp 00000000 103:05 332405 /lib/x86_64-linux-gnu/ld-2.23.so
7fc751ae6000-7fc751aeb000 rw-p 00000000 00:00 0
7fc751af3000-7fc751af4000 rw-p 00000000 00:00 0
7fc751af4000-7fc751af5000 r--p 00025000 103:05 332405 /lib/x86_64-linux-gnu/ld-2.23.so
7fc751af5000-7fc751af6000 rw-p 00026000 103:05 332405 /lib/x86_64-linux-gnu/ld-2.23.so
7fc751af6000-7fc751af7000 rw-p 00000000 00:00 0
7fff2855f000-7fff28580000 rw-p 00000000 00:00 0 [stack]
7fff285e9000-7fff285ed000 r--p 00000000 00:00 0 [vvar]
7fff285ed000-7fff285ef000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
terminate called after throwing an instance of 'std::logic_error'
what(): subprocess failed (exit code 6)
Also the script can be found: https://github.com/abcfy2/qBittorrent-Enhanced-Edition/blob/v4_3_x/.github/workflows/build_appimage.sh
I have really no clue what's failing here, and why. But I see you're using the latest AppImage again. So I can only guess the issue has been resolved?
Generally, please switch to Ubuntu 18.04, as 16.04 is EOL.
I can confirm I just encountered this issue recently: https://github.com/justdan96/tsMuxer/runs/3491151141?check_suite_focus=true
The Dockerfile I was using: https://github.com/justdan96/tsmuxer_build/blob/d87e047b40132fff7711f7c94011b629929c22a0/Dockerfile
I can see @abcfy2 has resolved the issue with:
dd if=/dev/zero of=/tmp/linuxdeploy-plugin-qt-x86_64.AppImage conv=notrunc bs=1 count=3 seek=8
dd if=/dev/zero of=/tmp/linuxdeploy-x86_64.AppImage conv=notrunc bs=1 count=3 seek=8
Would this be the recommended approach? Or should I use the AppImage from 2020-08-05 as @luspi has?
I think I found the solution:
After extracting both linuxdeploy-plugin-qt and linuxdeploy, make sure to delete ./linuxdeploy-plugin-qt-x86_64.AppImage
If you do not do that, then linuxdeploy will detect this AppImage file and try to use it and obviously fail. Only if you delete that AppImage (or remove the executable flags), then will it pick up the extracted files inside ./squashfs-root and list both the appimage and qt plugin as available!
If anyone is looking for a ready-to-go Docker recipe that resolves this issue and results in a working linuxdeploy with the Qt plugin:
# install linuxdeploy and the Qt plugin
RUN curl -sLo /usr/local/bin/linuxdeploy-x86_64.AppImage "https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-x86_64.AppImage"
RUN curl -sLo /usr/local/bin/linuxdeploy-plugin-qt-x86_64.AppImage "https://github.com/linuxdeploy/linuxdeploy-plugin-qt/releases/download/continuous/linuxdeploy-plugin-qt-x86_64.AppImage"
RUN chmod +x /usr/local/bin/linuxdeploy-x86_64.AppImage
RUN chmod +x /usr/local/bin/linuxdeploy-plugin-qt-x86_64.AppImage
# fix for issue of linuxdeploy in Docker containers
RUN dd if=/dev/zero of=/tmp/linuxdeploy-plugin-qt-x86_64.AppImage conv=notrunc bs=1 count=3 seek=8
RUN dd if=/dev/zero of=/tmp/linuxdeploy-x86_64.AppImage conv=notrunc bs=1 count=3 seek=8
# fix issue with AppImage complaining about missing folders
RUN mkdir /usr/lib/x86_64-linux-gnu/qt5/plugins/mediaservice
RUN mkdir /usr/lib/x86_64-linux-gnu/qt5/plugins/audio