Segfault on startup of AppImage

[VorpalBlade]

Version

0.12.25

Operating System

Linux

Distribution Method

AppImage (Linux)

Describe the issue

❯ ./git-butler_0.12.25_amd64.AppImage 
Cannot get default EGL display: EGL_SUCCESS
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
zsh: segmentation fault (core dumped)  ./git-butler_0.12.25_amd64.AppImage

It does display a completely black window for maybe half a second before crashing.

I tried to look at the coredump captured by systemd-coredump, but the backtrace is all questionmarks, not sure if that is due to the AppImage, or just due to lack of debug symbols.

Other GL/EGL programs such as glxinfo, eglinfo, glxgears, vulkaninfo etc all seem to work as expected (so I don't think my graphics are broken)

• OS: Arch Linux (which is a rolling release distro, most recently updated yesterday evening)
• Desktop: KDE Plasma 6.1.5 (Wayland)
• Lenovo Thinkpad T480 with Intel + Nvidia MX150 graphics (running in pure intel mode).
• Intel Core i7-8550U (Skylake)

How to reproduce

Just try to run the AppImage

Expected behavior

The AppImage shouldn't segfault, duh.

Relevant log output

No response

[Byron]

Thanks a lot for reporting!

GitButler binaries are compiled with debug symbols included, but I am not sure the AppImage preparation doesn't strip them. CC @ndom91 who knows everything about it.

It's possible that #4789 (Switch to Tauri v2) fixes the issue as well.

In the meantime, can you try another distribution mechanism, like .deb?

[VorpalBlade]

A deb doesn't really work on a distro that doesn't use apt/dpkg. Do you mean simply extracting the binaries from the deb into a local directory and trying to run them?

[ndom91]

Hmm so this looks like an issue I had with mismatched mesa versions on my Nix box.

Can you check which version of mesa you have installed? (Or if you're using the mesa-git pkg from the AUR?)

[VorpalBlade]

Sure, mesa is 1:24.2.3-1, which is the latest on Arch Linux.

[VorpalBlade]

@Byron I extracted the binary from the deb, and that binary runs fine.

[Byron]

@Byron I extracted the binary from the deb, and that binary runs fine.

Wow, that's something new and indeed I just wasn't aware of the fact that the distro doesn't natively support .deb. It's good that it runs though, and hopefully a more permanent solution is possible as well.

[VorpalBlade]

Most distros do not support deb.

• Only Debian and those based on Debian (such as Ubuntu, Mint and PopOS) use deb. That is a large chunk of the user base to be fair.
• Anything from the Red Hat / Fedora lineage will use RPM instead (as does Suse and a few others I believe).
• Arch (and derivatives) uses .pkg.tar.zst (very unimaginative name).
• Alpine has it's own inspired-by-Arch-but-sufficiently-different format called .apk (I think, the package building recipe format is at least very similar).
• Gentoo builds everything from source using .ebuild files
• I'm not quite sure what NixOS does, except it is fancy, isolated, reproducible and quite complex.
• And there are of course many more, less well known ones. (This family tree shows the proliferation of Linux distros.)

All formats are different enough to not be compatible of course. There was a reason I started with the AppImage (a flatpak would be another reasonable and nice option).

[ndom91]

Yeah the linux packaging landscape is a mess 😅. We support rpm and deb as first party formats, which as you mentioned cover a lot of users/distros, but of course not all.

That's partly why stuff like appimages/flatpaks/snaps were invented, in order to have a more universal packaging format for linux desktop. And why we also support appimages.

Of course with these universal packaging formats (flatpak, appimage, etc.), they all do some non-standard stuff like package with the binary all the libraries that might be required, mount the application as a separate squashfs, and so on which make them much more likely to trigger edge-cases like the one described here or the (infamous) "can't open external links on Linux/AppImage" thing 😅

Anyway, I'm glad you've got it working for you now, but I'd still like to figure out what was going on here.

I've got mesa@24.2.2 installed on my local box and AppImage is built on an ubuntu 22 GHA runner which would have 22.0.1 as far as I can tell. So we've both got significantly newer versions than it was built with 🤔

So maybe it's not that package.. What about libwebkit2gtk-4.0? Which version of that are you running?

[VorpalBlade]

❯ pacman -Ss libwebkit2gtk
extra/webkit2gtk 2.46.0-2 [installed]
    Web content engine for GTK
extra/webkit2gtk-4.1 2.46.0-2 [installed]
    Web content engine for GTK

Are the packages that are available and installed. The one without suffix is presumably 4.0 as it provides libjavascriptcoregtk-4.0.so=18-64 libwebkit2gtk-4.0.so=37-64. 4.1 meanwhile provides libjavascriptcoregtk-4.1.so=0-64 libwebkit2gtk-4.1.so=0-64

[ndom91]

Oh interesting. So theoretically the AppImage should use the version that comes with it, but maybe it links out to somehting on the host system and got confused. Because libwebkit2gtk-4.0 is required for Tauri v1 apps (like ours) and libwebkit2gtk-4.1 is only for Tauri v2 apps.

Would you be willing to satisfy my curiosity and see if uninstalling the libwebkit2gtk-4.1 helps? 😂

[VorpalBlade]

I mean, both are installed, so it shouldn't pick up the one with the wrong SO version? (Also uninstalling would require uninstalling a bunch of dependants that I'd rather not).

I tried using strace -f but that fails to mount the AppImage (fuse error) for some reason. If I use --appimage-mount to mount the image and then strace -f on the ./AppRun entry point, we get this log: gitbutler-strace.log

Anyway, this shows:

❯ grep webkit ~/gitbutler-strace.log  
openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/glibc-hwcaps/x86-64-v3/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/glibc-hwcaps/x86-64-v2/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC) = 3
[pid 2019457] execve("././/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess", ["././/lib/x86_64-linux-gnu/webkit"..., "1", "28", "30"], 0x6344a60192c0 /* 104 vars */ <unfinished ...>
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/glibc-hwcaps/x86-64-v3/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/glibc-hwcaps/x86-64-v2/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/libwebkit2gtk-4.0.so.37", O_RDONLY|O_CLOEXEC) = 3
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/glibc-hwcaps/x86-64-v3/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2019457] newfstatat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/glibc-hwcaps/x86-64-v3/", 0x7ffe24e362f0, 0) = -1 ENOENT (No such file or directory)
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/glibc-hwcaps/x86-64-v2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2019457] newfstatat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/glibc-hwcaps/x86-64-v2/", 0x7ffe24e362f0, 0) = -1 ENOENT (No such file or directory)
[pid 2019457] openat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 2019457] newfstatat(AT_FDCWD, "/tmp/.mount_git-buMFlRtb/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/", {st_mode=S_IFDIR|0755, st_size=0, ...}, 0) = 0

So it seems to use the right one.

I tried gdb, but since AppRun is a shell script it doesn't seem to work well. Running ./AppRun.wrapped fails in the same way (with no window even).

❯ ./usr/bin/git-butler  

** (git-butler:2022384): ERROR **: 12:13:53.406: Unable to spawn a new child process: Failed to spawn child process “././/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess” (No such file or directory)
zsh: trace trap (core dumped)  ./usr/bin/git-butler

But that is now getting pretty far off-track in how we realistically run things