[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- linux, rust, tauri
- Área
- build-system, desktop, operating-systems
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Rust
- Estrellas
- 2.3k
- Forks
- 236
- Merge medio
- 2 h 53 min
- PR fusionados (30 d)
- 604
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de GCWing/OpenBitFun
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
GCWing/OpenBitFun#3213 · 1 comentario ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
GCWing/OpenBitFun#2363 ·
-
question
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
GCWing/OpenBitFun#2340 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
GCWing/OpenBitFun#3225 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
GCWing/OpenBitFun#3222 ·
Todos los issues de GCWing/OpenBitFun
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
bug core
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Abiertofuzz
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ClickHouse/ClickHouse#122114 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
linebender/vello_svg#90 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100