[Development] What to do if tests hang on the CI and I can't reproduce that locally?

[Ilya Fedin]

On Tue, 14 May 2024 11:44:24 -0700
Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Tuesday 14 May 2024 09:23:50 GMT-7 Ilya Fedin wrote:
> > I fail to imagine how that could be... gtk shouldn't care how Qt
> > gets DPI and especially it shouldn't make it hang on XInternAtom
> > (which makes X server either to get an integer from its internal
> > string-integer map or increment the internal counter and add it to
> > the aforementioned map with the supplied string, as far as I
> > understand, no client-to-client messaging here).  
> 
> Think in terms of side-effects. It doesn't care how Qt does it, but
> the side- effect of what we are doing could be important, since we're
> sharing libxcb internal state, the xcb_connection (I think), and the
> X11 server itself.

It doesn't share xcb connection nor xlib display. If the trace was with
debug symbols for gtk, it would be easier to find what gtk does when
the side effect happens...

> Have you tried running a simple test like tst_qguichronotimer in a
> loop to see if it is indeed a race condition?

I remember I was trying to run cmptest lots of time, with different
environment variables, trying to recreating CI environment...

> In any case, if all else fails, declare it an undiagnosed GDK bug and
> detect whether our dispatcher is QXcbGlibEventDispatcher. If it is,
> then don't use the new feature.

That would disable the code for everyone as the glib dispatcher is
always used, even on KDE.