linuxdeploy: Crash in new subprocess library

I have a problem with getting linuxdeploy to work, even with a very simple application

I made a repository, which is a minimal example of what I’m trying to do, please take a look at try-deploy.sh https://github.com/muttleyxd/linuxdeploy-plugin-qt-crash-minimal-example

I tested this on two different distributions:

Arch Linux - it crashes under a second

<truncated logs, >
Setting rpath in ELF file build/testingdeploy/usr/lib/libxcb-xkb.so.1 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxkbcommon-x11.so.0 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxkbcommon.so.0 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libzstd.so.1 to $ORIGIN 

-- Running input plugin: qt -- 
Running process: /home/muttley/git/test/simple_qt_widgets_test/linuxdeploy-plugin-qt-x86_64.AppImage --appdir build/testingdeploy
[qt/stdout]   ld-linux-x86-64.so.2  libGL.so.1  libGLX.so.0  libGLdispatch.so.0  libICE.so.6  libQt5Core.so.5  libQt5DBus.so.5  libQt5Gui.so.5  libQt5Network.so.5  libQt5Pdf.so.5  libQt5Svg.so.5  libQt5Widgets.so.5  libQt5XcbQpa.so.5  libSM.so.6  libX11-xcb.so.1  libX11.so.6  libXau.so.6  libXdmcp.so.6  libbz2.so.1.0  libc.so.6  libcom_err.so.2  libcrypto.so.1.1  libdbus-1.so.3  libdl.so.2  libdouble-conversion.so.3  libexpat.so.1  libfontconfig.so.1  libfreetype.so.6  libgcc_s.so.1  libgcrypt.so.20  libglib-2.0.so.0  libgpg-error.so.0  libgraphite2.so.3  libgssapi_krb5.so.2  libharfbuzz.so.0  libicudata.so.67  libicui18n.so.67  libicuuc.so.67  libjpeg.so.8  libk5crypto.so.3  libkeyutils.so.1  libkrb5.so.3  libkrb5support.so.0  liblcms2.so.2  liblz4.so.1  liblzma.so.5  libm.so.6  libmd4c.so.0  libpcre.so.1  libpcre2-16.so.0  libpng16.so.16  libpthread.so.0  libresolv.so.2  librt.so.1  libssl.so.1.1  libstdc++.so.6  libsystemd.so.0  libuuid.so.1  libxcb-glx.so.0  libxcb-icccm.so.4  libxcb-image.so.0  libxcb-keysyms.so.1  libxcb-randr.so.0  libxcb-render-util.so.0  libxcb-render.so.0  libxcb-shape.so.0  libxcb-shm.so.0  libxcb-sync.so.1  libxcb-util.so.1  libxcb-xfixes.so.0  libxcb-xinerama.so.0  libxcb-xinput.so.0  libxcb-xkb.so.1  libxcb.so.1  libxkbcommon-x11.so.0  libxkbcommon.so.0  libz.so.1  libzstd.so.1
[qt/stdout] g module: dbus -- 
[qt/stdout] 
[qt/stdout] -- Deploying module: gui -- 
[qt/stdout] Deploying platform plugins 
[qt/stdout] eploying shared library /usr/lib/qt/plugins/platforms/libqxcb.so (destination: build/testingdeploy/usr/plugins/platforms/)
munmap_chunk(): invalid pointer
./try-deploy.sh: line 23: 185550 Aborted                 (core dumped) ./linuxdeploy-x86_64.AppImage --appdir build/testingdeploy --plugin qt --output appimage

Ubuntu 16.04 it takes longer, running qt plugin doesn’t fail, but after around a minute it also crashes

Setting rpath in ELF file build/testingdeploy/usr/lib/libpcre16.so.3 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libpng12.so.0 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxcb-glx.so.0 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxcb-present.so.0 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxcb-sync.so.1 to $ORIGIN 
Setting rpath in ELF file build/testingdeploy/usr/lib/libxshmfence.so.1 to $ORIGIN 

-- Running input plugin: qt -- 
Running process: /home/muttley/git/linuxdeploy-plugin-qt-crash-minimal-example/linuxdeploy-plugin-qt-x86_64.AppImage --appdir build/testingdeploy
[qt/stdout]   libGL.so.1  libQt5Core.so.5  libQt5Gui.so.5  libQt5Widgets.so.5  libX11-xcb.so.1  libX11.so.6  libXau.so.6  libXdamage.so.1  libXdmcp.so.6  libXext.so.6  libXfixes.so.3  libXxf86vm.so.1  libc.so.6  libdl.so.2  libdrm.so.2  libexpat.so.1  libffi.so.6  libfreetype.so.6  libgcc_s.so.1  libglapi.so.0  libglib-2.0.so.0  libgobject-2.0.so.0  libgraphite2.so.3  libharfbuzz.so.0  libicudata.so.55  libicui18n.so.55  libicuuc.so.55  libm.so.6  libpcre.so.3  libpcre16.so.3  libpng12.so.0  libpthread.so.0  librt.so.1  libstdc++.so.6  libxcb-dri2.so.0  libxcb-dri3.so.0  libxcb-glx.so.0  libxcb-present.so.0  libxcb-sync.so.1  libxcb.so.1  libxshmfence.so.1  libz.so.1

-- Copying files into AppDir -- 
munmap_chunk(): invalid pointer
./try-deploy.sh: line 23:  3100 Aborted                 (core dumped) ./linuxdeploy-x86_64.AppImage --appdir build/testingdeploy --plugin qt

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 20 (8 by maintainers)

Commits related to this issue

Temporary using old binaries because of unstable linuxdeploy lib https://github.com/linuxdeploy/linuxdeploy/issues/143 — committed to FreeRDP/Remmina by antenore 4 years ago
Switch to new subprocess lib in type 0 plugins, mk. 2 Apparently fixes all buffer-related crashes, but there's a few minor bugs left. CC #143 — committed to linuxdeploy/linuxdeploy by TheAssassin 4 years ago
Switch to new subprocess lib in type 0 plugins, mk. 3 This commit fixes the remaining buffer issues by introducing a little more complexity. It shall be refactored in the future to decrease complexit... — committed to linuxdeploy/linuxdeploy by TheAssassin 4 years ago

Most upvoted comments

may I suggest, that this project starts using releases and tags?

There’s nearly no external contribution to this tool and most other AppImage tools, most people just use them. If there were, I might have more time for testing new features more thoroughly. However, that’s not possible due to my lack of time. Therefore, some “public beta testing” in the form of providing continuous builds is the best I can offer. Releasing takes a lot of time and effort, I can tell from my other projects. However, to always have some working binaries, I started this “old builds retention” to be able to provide links to stable builds any time. Another problem with “versioning” is that no other component in the AppImage eco system is properly versioned, the few tools which do releases just all invent their own scheme. I’d rather stick with “continuous” therefore. The third rationale against making releases is that we’ve experienced people never really update those components once they have “one that works”, which is also not in our best interest. I hope the future AppImage type 3 will fix a lot of the underlying issues (as it introduces some standards with proper versioning). Only then, I would consider making releases of linuxdeploy…

I promised I will look into fixing the issue today. I just got home and will start rewriting the problematic bits now. Please track this issue, I’ll keep it updated. Also, I invite everyone to help test the new binaries then and make sure the issues are gone.

TheAssassin on Aug 11, 2020

Took me a few days longer than I wanted (real life stuff, you probably know that…), but I finished that new subprocess library, dumped the old relicts, switched everything over and so far, it’s looking good! There’s only a few minor output-related issues (which should not affect builds very much, mostly there’s some characters missing here and there in log messages, nothing critical) remaining which need to be taken care of.

Now, I need you to test the new (upcoming) builds in real life. I’ve run some lengthy tests (with e.g., the Qt plugin on some larger projects, where there’s lots of logging) and had no crashes so far, but well, the last build passed similar tests, too, so I’m interested in your feedback. Let me know if there’s any issues.

TheAssassin on Aug 31, 2020

Argh, now I reopened it even… sorry!

TheAssassin on Sep 7, 2020

may I suggest, that this project starts using releases and tags? In our company all CI stopped working due to using the continious tag. I guess this could result in better issue descriptions too, when the reporter can report, that he’s using version 1.2.3 instead of version 1-alpha (git commit ID e91b459).

This tool seems production ready to me, am I wrong?

Anyway, thx for the great tool and your work! Till now, it just worked and did an awesome job! 😃

qwertzui11 on Aug 11, 2020

As recommended in #141 and #142, you can find older, working binaries in https://artifacts.assassinate-you.net/artifactory/list/linuxdeploy/travis-456/. Please use them until this issue has been resolved.

TheAssassin on Aug 9, 2020

Moved this issue into the right tracker. Please try to use the latest continuous build, which increases some buffer sizes. I’ve switched to a new library and it’s a little unstable with its subprocess handling right now. Will be fixed ASAP, but not before Tuesday.

TheAssassin on Aug 8, 2020

Was just about to close it myself. Ran some more tests, everything looks alright.

TheAssassin on Sep 7, 2020

I managed to fix the remaining buffer-related issues, as far as I can see. We need some more in-depth testing, especially with third party plugins, but I’m very confident at this point. The code has become a bit complex, but it can always be refactored later on. For now, function is more important.

Right now, I’m waiting for the AppImages to be built by Travis, and will then run the build scripts for a bunch of projects.

TheAssassin on Sep 4, 2020

Well, my builds seem to pass again so looking good to me at least: https://travis-ci.org/github/Pext/Pext/builds/722635673

TheLastProject on Aug 31, 2020

There’s a link earlier on in the thread to a host with some older builds. They worked for me.

ndarilek on Aug 30, 2020