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

On 2026-01-02 10:10, Jon Turney wrote:
> 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...)

Hi Jon,

Under GH scallywag CI, ctest now runs normally under xvfb_run first time thru, 
but it looks like it hangs or loops after ctest and never gets back to src_test 
as there is no debug output: see job 10935.

Looks like only kill could be hanging or looping, and could adding -f help?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry