Bug#1109274: mutter: intermittent test failure in xwayland test: Child process exited with code 1

Simon McVittie smcv at debian.org
Mon Jul 14 14:12:04 BST 2025


Source: mutter
Version: 48.4-2
Severity: important
Tags: ftbfs unreproducible
User: debian-ci at lists.debian.org
Usertags: flaky

In one autopkgtest on ppc64el, 
https://ci.debian.net/packages/m/mutter/testing/ppc64el/62167381/ we can 
see this failure:

>609s # Running test: mutter-16/xwayland.test
>611s # Executing: mutter-16/xwayland.test
>611s # FAIL: mutter-16/xwayland.test (Child process exited with code 250)
>611s not ok - mutter-16/xwayland.test
...
>652s # SUMMARY: total=34; passed=31; skipped=0; failed=3; user=54.7s; system=14.5s; maxrss=1146276
...
>652s # FAIL: mutter-16/xwayland.test (Child process exited with code 250)

For further details of that failure we have to look in the 
$AUTOPKGTEST_ARTIFACTS (artifacts.tar.gz on ci.debian.net) and read 
artifacts/mutter-16_xwayland.test.txt, quoted in full here:

>Setup HOME as /tmp/mutter-testroot-ksve67fk/home
>Setup TMPDIR as /tmp/mutter-testroot-ksve67fk/tmpdir
>Setup XDG_CACHE_HOME as /tmp/mutter-testroot-ksve67fk/xdg_cache_home
>Setup XDG_CONFIG_HOME as /tmp/mutter-testroot-ksve67fk/xdg_config_home
>Setup XDG_DATA_HOME as /tmp/mutter-testroot-ksve67fk/xdg_data_home
>Setup XDG_RUNTIME_DIR as /tmp/mutter-testroot-ksve67fk/xdg_runtime_dir
>Starting D-Bus daemons (session & system)...
>Binding /tmp/mutter-testroot-ksve67fk/xdg_runtime_dir/pipewire-0 for socket activation
>Binding /tmp/mutter-testroot-ksve67fk/xdg_runtime_dir/pipewire-0-manager for socket activation
>Launching required services...
>Starting mocked services...
>ERROR:dbus.proxies:Introspect error on :1.1:/org/freedesktop/login1/session/dummy: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/dummy'.
>Running test case...
>Process ['/usr/libexec/installed-tests/mutter-16/mutter-xwayland'] started with pid 7648
>TAP version 14
># random seed: R02Sf7315ed43b1f8d8533e16a903f372db9
># GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation memory (GMemorySettingsBackend) for ‘gsettings-backend’
># GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used after threads are created
># libmutter-MESSAGE: Running Mutter Test (using mutter 48.4) as a Wayland display server
># libmutter-MESSAGE: Created surfaceless renderer without GPU
># GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
># libmutter-DEBUG: WL: Unable to initialize wl_eglstream_controller.
># libmutter-MESSAGE: Using public X11 display :512, (using :513 for managed services)
># libmutter-MESSAGE: Using Wayland display name 'mutter-test-display'
>1..4
># Start of backends tests
># Start of xwayland tests
># Start of compositor tests
># libmutter-INFO: Acquired name org.gnome.Mutter.InputMapping
># libmutter-DEBUG: Acquired name org.freedesktop.a11y.Manager
># libmutter-INFO: Acquired name org.gnome.Mutter.ServiceChannel
>Xwayland glamor: GBM Wayland interfaces not available
>Failed to initialize glamor, falling back to sw
>NO X11 Compositor is available for display :512:0
>**
>mutter-xwayland-test:ERROR:../src/tests/xwayland-tests.c:257:compositor_check_proc_async: assertion failed (error == NULL): Child process exited with code 1 (g-spawn-exit-error-quark, 1)
>not ok /backends/xwayland/compositor/selection - mutter-xwayland-test:ERROR:../src/tests/xwayland-tests.c:257:compositor_check_proc_async: assertion failed (error == NULL): Child process exited with code 1 (g-spawn-exit-error-quark, 1)
>Bail out!
>(EE) failed to read Wayland events: Connection reset by peer
>Closing PipeWire socket...
>Terminating services...
>
>(mutter-x11-frames:7694): Gtk-WARNING **: 09:16:49.718: Failed to open display

This could perhaps be a race condition: maybe the test client is racing 
with startup of the Wayland compositor, such that if the compositor wins 
the race (as it usually does), everything will work as expected, but if 
the test client wins the race, the test will fail? But that's only a 
theory.

I've only observed this once on ci.debian.net, but in principle it 
ought to affect autopkgtest and build-time tests equally, hence the 
ftbfs tag.

    smcv



More information about the pkg-gnome-maintainers mailing list