When running layout tests on a headless bot (WPE Debug Tests for instance), the "setup_a11y_proxy()" method emits a warning and returns an empty list: Error connecting: Cannot autolaunch D-Bus without X11 $DISPLAY Failed to get a11y address Command '('gdbus', 'call', '-e', '-d', 'org.a11y.Bus', '-o', '/org/a11y/bus', '-m', 'org.a11y.Bus.GetAddress')' returned non-zero exit status 1. I suspect that's then triggering a bunch of accessibility timeouts on the bot and harness bails out early... On this specific bot (https://build.webkit.org/#/builders/14) it seems(?) there's no dbus running at all either... If we want to keep running this gdbus call that early (before xvfb has been started), we need to make sure all bots have a working dbus setup, since auto-launching clearly is not working out.
Maybe run xvfb under dbus-run-session?
The layout tests don't use atspi service at all, so we don't needs to start it. It's needed for the unit tests, though.
The WebProcess becomes un-responsive on the WPE Debug bot, I don't know why: 20:30:56.465 3 worker/0 starting 20:30:56.467 3 worker/1 starting 20:30:56.468 3 worker/2 starting 20:30:56.470 3 worker/3 starting 20:30:56.472 3 worker/4 starting 20:31:11.825 3 worker/1 WPEWebProcess is unresponsive, pid = None 20:31:11.829 3 worker/4 WPEWebProcess is unresponsive, pid = None 20:31:11.829 3 worker/2 WPEWebProcess is unresponsive, pid = None 20:31:11.832 3 worker/0 WPEWebProcess is unresponsive, pid = None 20:31:11.834 3 worker/2 worker/2 animations/CSSKeyframesRule-name-null.html output stderr lines: 20:31:11.842 3 worker/2 Failed to load 'about:blank', terminating process and trying again. 20:31:11.843 3 worker/2 WPEWebProcess terminated (pid 0) for reason: requested by client 20:31:11.843 3 worker/2 Failed to load 'about:blank' again after termination. 20:31:11.844 3 worker/2 <unknown> - TestController::run - Failed to reset state to consistent values 20:31:11.844 3 worker/2 #PROCESS UNRESPONSIVE - WPEWebProcess
And it seems this has been going possibly since February 2022.
Another issue, possibly orthogonal to this one here, but might contribute to timeouts... we keep gathering crash dumps even for expected crashes. Isn't that a bit of a waste of virtual virtual CPU cycles? Expected crashes are not linked in the results page.