#981201 autopkgtests that use xvfb are flaky on slow architectures

Package:
xvfb
Source:
xorg-server
Description:
Virtual Framebuffer 'fake' X server
Submitter:
Sebastien Bacher
Date:
2025-02-08 13:42:02 UTC
Severity:
normal
#981201#5
Date:
2021-01-27 16:08:19 UTC
From:
To:
The issue is quite noticable on arm64 Ubuntu
https://autopkgtest.ubuntu.com/packages/b/bambam/hirsute/arm64

Using the -noreset xvfb-run option fixes the issue, that's similar to
fixes applied to other Debian packages
https://salsa.debian.org/a11y-team/pyatspi/commit/c8406c19
being one example

Thanks,
#981201#10
Date:
2021-01-27 16:30:37 UTC
From:
To:
Thanks for the report, Sebastien!
I'd like to understand the issue better. Can you please point me at an
example flake?

Marcin
#981201#15
Date:
2021-01-27 17:36:12 UTC
From:
To:
Hey, thanks for the reply!

One example of failing test log
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/arm64/b/bambam/20210118_202718_49256@/log.gz

It's a frequent problem with xvfb, you can search for noreset use on
google or debian codesearch to see other packages where similar issues
were reported

I can easily trigger the issue on an arm64 instance on Canonistack,
doing a loop on the xvfb command it fails ~30% of the time, with the
patch it's always successful

Cheers,

Le 27/01/2021 à 17:30, Marcin Owsiany a écrit :
#981201#20
Date:
2021-01-27 17:46:30 UTC
From:
To:
Thanks, I'll check it out.

My concern here is that we're effectively papering over some issue in xvfb,
in multiple places rather than fixing it once properly at the source.

Marcin
#981201#25
Date:
2021-01-27 18:50:58 UTC
From:
To:
Le 27/01/2021 à 18:46, Marcin Owsiany a écrit :

Ideally that wouldn't be needed indeed, fixing it in xvfb if possible
would be best.

Cheers,
#981201#30
Date:
2021-01-28 08:28:05 UTC
From:
To:
reassign 981201 xvfb
thanks

I've submitted a pull request against xvfb-run to achieve this.
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/6
Hopefully the X strike force folks will look at it kindly.

FWIW, the way this can be reproduced easily even on amd64 is:
1. in first terminal, run "Xvfb :66"
2. in second terminal, run "DISPLAY=:66 xeyes"
3. in third terminal, run xlsclients in a tight loop: "while :;do
DISPLAY=:66 xlsclients || echo FAIL;done" - it will produce a stream of
"yourhostname xeyes"
4. then press CTRL+C in the second terminal
5. notice how in the third terminal, xlsclients has failed to connect
#981201#49
Date:
2025-02-08 13:39:13 UTC
From:
To:
Control: retitle -1 xvfb-run: makes tests flaky if multiple clients connect without -noreset

I've retitled #981201 to try to make it more obvious that #981201 is
about the situation where a test connects more than one client to the
X server, passing through a state where 0 clients are connected in the
process, and does not pass -noreset to xvfb-run. I think race conditions
in starting up Xvfb for the first time (#1095028) should be considered
out-of-scope for this particular bug report.

The solution to #981201 that Marcin Owsiany proposed in
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/6
was to make -noreset the default, but the Xorg team are concerned that
changing the default could break expectations.

(I wonder whether this might mean that xvfb-run should have a
debhelper-like concept of having a compat level, defaulting to -reset in
compat level 1 and -noreset in compat level >= 2? But perhaps that's
overkill.)

The workaround that many packages are now using for their build-time
tests and/or autopkgtests is to use `xvfb-run -a -s "-noreset"` as their
"adverb" command.

    smcv