[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 68/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- linux, rust, tauri
調査の方向性
Start by locating the Linux AppImage build configuration and its linuxdeploy packaging rules. Exclude libwayland-client.so.0 and the other host-coupled graphics libraries described in the issue, rebuild and test the extracted AppImage on a newer Mesa host, then verify that WebProcess stays alive, the UI renders, and latest.json remains valid for updates.
索引モデルが issue の本文から書いたものです。
説明
Summary
On an Arch-based host (EndeavourOS) running Mesa 26.x + libglvnd, the official linux-x86_64 AppImage (v1.0.1) opens but stays blank/white. WebKit's WebProcess aborts during EGL initialization and never comes back:
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...
The GTK shell window survives, so the user-visible symptom is a permanent blank window rather than a crash.
This appears to be the same AppImage packaging issue documented for another Tauri + WebKitGTK app here: https://github.com/sftwrdotdev/Markpad/issues/498
Environment
- Host: EndeavourOS (Arch-based), x86_64, VM without usable GPU (VMware 3D acceleration off; software rendering via llvmpipe)
- Mesa 1:26.2.2, libglvnd 1.7.0, system webkit2gtk-4.1 2.52.6
- Session: X11 via xrdp/Xvnc (
DISPLAY=:10) - OpenBitFun v1.0.1 AppImage (
OpenBitFun_1.0.1_linux-x86_64.AppImage)
Symptoms / observed behavior
- stderr right after the banner
=== OpenBitFun Desktop Starting ===:Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...(pure-Mesa environment)- On a system that additionally carries leftover NVIDIA EGL vendor files (
/usr/share/glvnd/egl_vendor.d/10_nvidia.json,libnvidia-*.so), the first failure instead surfaces asCould not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting...— same root area, different vendor path.
- No
WebKitWebProcessis ever alive (it dies at startup); onlyWebKitNetworkProcesssurvives, so the page never renders. webview.logstays 0 bytes;app.logshowsStartup page did not finish loading before the window reveal watchdog.- Reproduced both from the FUSE-mounted AppImage and via
--appimage-extract-and-run. A strace of the dying WebProcess shows it loading/usr/lib/libEGL.so.1(glvnd), then aborting right after vendor probing — before any DRI driver is reached.
Root cause analysis
The AppImage bundles usr/lib/libwayland-client.so.0 (built against the ubuntu-24.04 runner). Because LD_LIBRARY_PATH puts the AppImage directories first, that older copy shadows the host's libwayland-client for every process in the AppImage tree, including WebKit's WebProcess. The host libEGL (libglvnd) links libwayland-client, and with the mismatched older copy in place, eglGetPlatformDisplay is rejected at the EGL dispatch entry with EGL_BAD_PARAMETER before any DRI driver is even loaded (Mesa verbose logging prints nothing useful, consistent with a rejection at dispatch entry).
This matches exactly the single-library isolation result reported in Markpad #498 (same stack: Tauri + WebKitGTK 2.52.x AppImage built on ubuntu-24.04, tested on Arch/Mesa 26): removing only libwayland-client.so.0 from the AppDir is necessary and sufficient — the full UI then renders.
Verification performed (on this host)
- Extracted the published v1.0.1 AppImage to a directory (
--appimage-extract). - Deleted only
squashfs-root/usr/lib/libwayland-client.so.0. - Ran the extracted
AppRunwithWEBKIT_DISABLE_DMABUF_RENDERER=1on an X11 session. - Result:
WebKitWebProcessstays alive, no EGL abort on stderr,webview.logfills up — the frontend completes full startup (Tauri API initialized, Monaco Editor initialized, I18n / config / language registries ready) and no watchdog warning is emitted. UI renders normally.
Note: env workarounds alone (WEBKIT_DISABLE_DMABUF_RENDERER=1, WEBKIT_DISABLE_COMPOSITING_MODE=1, LIBGL_ALWAYS_SOFTWARE=1) do not fix the shipping AppImage — consistent with Markpad #498's findings.
Suggested fix
Exclude host-coupled graphics libraries from the AppImage at build time (linuxdeploy excludelist, per AppImageCommunity/pkg2appimage guidance) — at minimum libwayland-client.so.0, ideally the full set: libwayland-*, plus libEGL/libGL/libgbm/libdrm/libxcb* if present.
Caveat for maintainers: a repacked AppImage must be re-signed and latest.json regenerated, or the auto-updater breaks (same note as in Markpad #498).
Repro caveat
The bug is host-version dependent: it only manifests when the host's Mesa/libwayland are newer than the build runner's. Builds and tests on the ubuntu-24.04 runner (or on hosts matching it) will not catch this; a CI smoke test on a recent Arch/Mesa image would have caught both this and any future recurrence of the same class of packaging problem.
- 主要言語
- Rust
- スター
- 2.3k
- フォーク
- 236
- 平均マージ
- 2時間 53分
- マージ済み PR(30日)
- 604
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
GCWing/OpenBitFun のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
GCWing/OpenBitFun#3213 · コメント 1 件 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
GCWing/OpenBitFun#2363 ·
-
question
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
GCWing/OpenBitFun#2340 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
GCWing/OpenBitFun#3225 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
GCWing/OpenBitFun#3222 ·
GCWing/OpenBitFun の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
TheLarkInn/aipm#2413 ·
-
documentation
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
alexgorbatchev/simple-ptt#15 ·
-
tooling
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
todo:ticket
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
taikoxyz/taiko-mono#22168 · コメント 1 件 ·