Re: cygport xvfb.cygclass xvfb_run now hangs under GH scallywag

On 31/12/2025 00:35, Brian Inglis via Cygwin-apps wrote:
> On 2025-12-28 13:57, Brian Inglis wrote:
>> On 2025-12-28 13:21, Brian Inglis wrote:
>>> On 2025-12-28 11:09, Brian Inglis wrote:
>>>> While testing zint under GH scallywag (10903), cygport check ctest 
>>>> now hangs after running xvfb_run cygdrop ... ctest and had to be 
>>>> cancelled.
>>>> Everything worked fine for my previous zint updates up to 2025-03-01 
>>>> (9484).
>>>>
>>>> After adding b-r xorg-server-extra, using that package's xvfb-run 
>>>> (instead of xvfb.cygclass xvfb_run) works, but now with two test 
>>>> failures, under both GH scallywag (10907) and locally.
>>>>
>>>> Does something need to be tweaked in xvfb_run xvfb.cygclass to have 
>>>> it use or work more like xorg-server-extra xvfb-run and avoid 
>>>> hanging but avoid issues?
>>>
>>> By contrast, locally, cygport check "hangs" at end *after* running 
>>> tests, with gam_server, bash, subshell, and tee still running, where 
>>> GH scallywag hangs starting ctest.

Note that you'll need to unset DISPLAY, if it points to a local server 
you're already running, to replicate what happens in the CI job - 
otherwise cygport just uses the existing server...

> Modified playground cygport to check for $GITHUB_WORKFLOW = scallywag 
> and run ctest under xvfb-run then run under xvfb_run with -xv enabled, 
> which loops starting an X server, running xmodmap, killing xvfb, 
> deleting X tmp lock and socket, incrementing xvfb_display, and repeats: 
> see GH scallywag zint job 10923.

Well, this is odd.

I don't think there's been a change in the actual server in this timeframe.

cygport's xvfb_run function is a bit of a misnomer, since it actually 
runs Xorg server with the 'dummy' driver.

I was thinking maybe some recent changes to xinit might be causing a 
problem, but xvfb.cygclass actually has custom implementation of that 
logic, to allow it to run a bash function (rather than just an 
executable) against the server.

Huh, well, looking into it a bit more, that logic looks a bit suspect:

It can loop forever if there's a problem starting the xserver, and it 
will probably fail if the hardware we're running on is too fast...

I've released cygport 0.37.6, with a bit of a hack to better allow for 
that, let's see if that improves anything.


(As an aside, I'm a bit curious why you moved the cmake files to 
/usr/lib/cmake.  Unless they are arch-dependent in some way, they belong 
in /usr/share...)