Skip to content

fix(ci): run pluginval under xvfb so the Editor test has a display - #4

Merged
gustavokch merged 3 commits into
mainfrom
pr3-review-followups
Jun 15, 2026
Merged

fix(ci): run pluginval under xvfb so the Editor test has a display#4
gustavokch merged 3 commits into
mainfrom
pr3-review-followups

Conversation

@gustavokch

Copy link
Copy Markdown
Owner

Summary

pluginval's Editor test opens the egui editor, which creates a real X11/GL window via baseview. Headless CI has no DISPLAY, so window creation segfaults (SIGSEGV) right at the Editor test — earlier Open-plugin tests pass because the crash is in editor paint, not load.

Install xvfb and wrap the pluginval invocation in xvfb-run -a, giving the test a virtual display. Keeps GUI test coverage instead of dropping it via --skip-gui-tests.

Verification

  • Reproduced: env -u DISPLAY -u WAYLAND_DISPLAY pluginval --strictness-level 8 --validate … → exit 139 (SIGSEGV) at the Editor test.
  • Fixed: same bundle + command under xvfb-run -a → SUCCESS (strictness 8).

Root cause + reproduction recorded in docs/plans/2026-06-14-pr3-review-followups.md known-issues.

pluginval's Editor test opens the egui editor, which creates a real
X11/GL window via baseview. Headless CI has no DISPLAY, so window
creation segfaults (SIGSEGV) right at the Editor test — earlier
Open-plugin tests pass because the crash is in editor paint, not load.

Install xvfb and wrap the pluginval invocation in xvfb-run -a, giving
the test a virtual display. Verified: same command + bundle succeeds
under xvfb locally, segfaults (exit 139) with no display. Keeps GUI
test coverage instead of dropping it via --skip-gui-tests.

Record root cause and fix in the PR #3 follow-ups known-issues note.
With a display present, the Editor test still aborted (exit 134) with
'Could not fetch framebuffer config: CreationFailed(InvalidFBConfig)'
from baseview, then a non-unwinding panic across the C FFI boundary.

baseview asks GLX for an RGBA framebuffer config. The runner has no GPU
and CI installed only libgl-dev (the libGL ABI), not Mesa's software DRI
driver, so GLX could produce no usable FBConfig. Not reproducible on a
dev box that already has Mesa swrast/llvmpipe, which is why the bare-xvfb
fix looked complete locally.

Install libgl1-mesa-dri (llvmpipe/swrast), force software GL via
LIBGL_ALWAYS_SOFTWARE=1, and start xvfb with a 24-bit GLX screen so an
RGBA FBConfig exists. Verified locally: pluginval strictness 8 runs to
SUCCESS through all three editor sub-tests.
pluginval's Editor test opens a real X11/GL window via baseview, which
needs an OpenGL/GLX framebuffer config. The GHA runner has no GPU/DRM
node, so client-side software rendering can't supply FBConfigs and GLX
falls back to indirect (server-side) GLX, which modern Mesa has dropped.
GLX then advertises zero FBConfigs and baseview aborts with
InvalidFBConfig (exit 134, non-unwinding panic across the C FFI).

Two attempts to provide a headless GL stack both failed: bare xvfb, then
xvfb + libgl1-mesa-dri + LIBGL_ALWAYS_SOFTWARE + a 24-bit GLX screen (CI
logs confirmed Mesa/llvmpipe installed, so it was not a missing driver).
Reproduced the indirect-GLX = 0-FBConfigs failure locally and confirmed
+iglx does not help.

Run pluginval with --skip-gui-tests instead. All non-GUI conformance
(params, buses, state, fuzz, threading) still runs; verified locally
that headless --skip-gui-tests passes at strictness 8. The editor is
verified manually in Carla (docs/img/stage3-egui-carla-render.png).

Reverts the xvfb/mesa CI additions from the two prior attempts.
@gustavokch
gustavokch merged commit 4608f6d into main Jun 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant