Failed to run (null): Bad address [with APPIMAGE_EXTRACT_AND_RUN=1]

[probonopd]

This happens on GitHub Actions and can be reproduced in GitHub Codespaces:

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
(...)

# https://github.com/AppImage/appimagetool/releases/tag/continuous
wget https://github.com/probonopd/PrusaSlicer/releases/download/mk1/PrusaSlicer-2.9.0-alpha1-x86_64.AppImage
chmod +x PrusaSlicer-2.9.0-alpha1-x86_64.AppImage 
./PrusaSlicer-2.9.0-alpha1-x86_64.AppImage --appimage-extract
wget https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
chmod  +x appimagetool-x86_64.AppImage 
rm PrusaSlicer-2.9.0-alpha1-x86_64.AppImage 

export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-x86_64.AppImage squashfs-root/
Failed to run (null): Bad address

sudo ./appimagetool-x86_64.AppImage squashfs-root/
# WORKS

sudo -E ./appimagetool-x86_64.AppImage squashfs-root/
# FAILS

unset APPIMAGE_EXTRACT_AND_RUN
sudo -E ./appimagetool-x86_64.AppImage squashfs-root/
# WORKS

[probonopd]

Might be caused by something in type2-runtime? But apparently it was not introduced by PIE since it also happens with a runtime from before that.

[brunvonlope]

I am experiencing the same bug: https://gnome.pages.gitlab.gnome.org/-/gimp/-/jobs/4538262/artifacts/appimagetool.log

[probonopd]

According to my tests, this is caused by

• Build static PIE binaries with clang #88

[TheAssassin]

I don't see how it's related. I'll have a quick look soon-ish.

[TheAssassin]

The latest release build (attempt) after merging #97 failed for some weird reason. Apparently, Alpine have fixed their GCC. See https://github.com/AppImage/type2-runtime/actions/runs/12209442497/job/34064245228. The i386 build failed, the rest should have worked. Please investigate.

[TheAssassin]

Side note: we probably want to pin Alpine and its packages precisely in the future to prevent something like that from happening.

[TheAssassin]

Cannot reproduce on a regular installation of Ubuntu 24.04.1. I suspect it is FUSE that is to blame here. Works fine in Docker with Ubuntu 20.04 as well, both when using the extract-and-run feature and regularly:

root@b950b46f9846:/ws# ./appimagetool-x86_64.AppImage 
Error: No suitable fusermount binary found on the $PATH
fuse: device not found, try 'modprobe fuse' first

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory
root@b950b46f9846:/ws# ./appimagetool-x86_64.AppImage  --appimage-extract-and-run
appimagetool, continuous build (git version c202322), build 192 built on 2024-12-03 20:05:47 UTC
file command is missing but required, please install it

I suspect that FUSE might be to blame here, especially when considering that Ubuntu 20.04 still ships libfuse2 by default... I'm just not convinced it is the PIE build that is to be blamed here. Your test implies that, too.

Edit: I suggest that you A/B test this properly. You have not proven that a non-PIE binary works, i.e., one produced right before the PR was merged. I cannot reproduce the failure right now, hence you need to carry out the testing.

[probonopd]

# When using the older appimagetool 1.9.0, it works:

rm -f appimagetool-*
wget https://github.com/AppImage/appimagetool/releases/download/1.9.0/appimagetool-x86_64.AppImage
chmod  +x appimagetool-x86_64.AppImage 
rm PrusaSlicer-2.9.0-alpha1-x86_64.AppImage 
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-x86_64.AppImage squashfs-root/

# But not with the new one:

rm -f appimagetool-*
wget https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
chmod  +x appimagetool-x86_64.AppImage 
rm PrusaSlicer-2.9.0-alpha1-x86_64.AppImage 
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-x86_64.AppImage squashfs-root/
Failed to run (null): Bad address

# Now the question is why the old appimagetool works but the new doesn't. Is a change in appimagetool at fault or a change in type2-runtime?

# Let's repackage the old appimagetool 1.9.0 using the continuous type2-runtime:
mv appimagetool-x86_64.AppImage appimagetool-continuous-x86_64.AppImage
rm -rf squashfs-root/
chmod +x appimagetool-1.9.0-x86_64.AppImage 
rm -rf squashfs-root/
./appimagetool-1.9.0-x86_64.AppImage --appimage-extract
VERSION=1.9.0+new_runtime ./appimagetool-continuous-x86_64.AppImage squashfs-root/
unset APPIMAGE_EXTRACT_AND_RUN
sudo VERSION=1.9.0+new_runtime ./appimagetool-continuous-x86_64.AppImage squashfs-root/

# So the old appimagetool with the new runtime also fails:
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-1.9.0+new_runtime-x86_64.AppImage squashfs-root/
Failed to run (null): Bad address

# This leads me to conclude that the error is changed by some change in the runtime
# Now let's check what happens if we do the same but with an older runtime

# https://github.com/user-attachments/files/18020807/runtime-x86_64.zip is from
# https://github.com/AppImage/type2-runtime/pull/86#issuecomment-2501966967

wget https://github.com/user-attachments/files/18020807/runtime-x86_64.zip
unzip runtime-x86_64.zip 
unset APPIMAGE_EXTRACT_AND_RUN
sudo VERSION=1.9.0+older_runtime ./appimagetool-continuous-x86_64.AppImage squashfs-root/ --runtime-file=runtime-x86_64
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-1.9.0+older_runtime-x86_64.AppImage ./PrusaSlicer.AppDir/

# It WORKS
# This leads me to conclude that a change since Nov 26, 2024 in the type2-runtime must be the culprit.
# Candidates:
# auto_unmount
# Build static PIE binaries with clang
# Update squashfuse to latest release
# Make binaries position independent

# So let's try with "Update squashfuse to latest release"

# https://github.com/user-attachments/files/18020913/runtime-x86_64.zip is from
# https://github.com/AppImage/type2-runtime/pull/89#issuecomment-2505419069

rm runtime-x86_64*
wget https://github.com/user-attachments/files/18020913/runtime-x86_64.zip
unzip runtime-x86_64.zip 
unset APPIMAGE_EXTRACT_AND_RUN
sudo VERSION=1.9.0+latest_squashfuse ./appimagetool-continuous-x86_64.AppImage squashfs-root/ --runtime-file=runtime-x86_64
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-1.9.0+latest_squashfuse-x86_64.AppImage ./PrusaSlicer.AppDir/

# IT WORKS
# So we check with "Build static PIE binaries with clang"

# https://github.com/user-attachments/files/18021013/runtime-x86_64.zip is from
# https://github.com/AppImage/type2-runtime/pull/88#issuecomment-2504960856

rm runtime-x86_64*
wget https://github.com/user-attachments/files/18021013/runtime-x86_64.zip
unzip runtime-x86_64.zip 
unset APPIMAGE_EXTRACT_AND_RUN
sudo VERSION=1.9.0+pie ./appimagetool-continuous-x86_64.AppImage squashfs-root/ --runtime-file=runtime-x86_64
export APPIMAGE_EXTRACT_AND_RUN=1
./appimagetool-1.9.0+pie-x86_64.AppImage ./PrusaSlicer.AppDir/
Failed to run (null): Bad addres

[probonopd]

Side note: we probably want to pin Alpine and its packages precisely in the future to prevent something like that from happening.

Absolutely! In case Alpine made other unrelated changes, then those might be at fault as well.

[probonopd]

The latest release build (attempt) after merging #97 failed for some weird reason.

Possibly because the Dockerfile did not pin Alpine.

With
FROM ${docker_arch}/alpine:3.20
it builds.

[probonopd]

It is working again:
https://github.com/probonopd/PrusaSlicer/actions/runs/12212215113/job/34070407500