Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window

オープン
#3,226 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
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 as Could not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting... — same root area, different vendor path.
  • No WebKitWebProcess is ever alive (it dies at startup); only WebKitNetworkProcess survives, so the page never renders.
  • webview.log stays 0 bytes; app.log shows Startup 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)

  1. Extracted the published v1.0.1 AppImage to a directory (--appimage-extract).
  2. Deleted only squashfs-root/usr/lib/libwayland-client.so.0.
  3. Ran the extracted AppRun with WEBKIT_DISABLE_DMABUF_RENDERER=1 on an X11 session.
  4. Result: WebKitWebProcess stays alive, no EGL abort on stderr, webview.log fills 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

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

GCWing/OpenBitFun のほかの issue

GCWing/OpenBitFun の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。