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

[Ilya Fedin]

On Tue, 14 May 2024 16:42:17 -0700
Thiago Macieira <thiago.macieira at intel.com> wrote:

> > I'm doubt that's the case here though given that it
> > doesn't hang with other patches. The only theory I can wrap my head
> > of is that querying RESOURCE_MANAGER property momentally after it
> > changes breaks X server somehow. I tried to queue reading the
> > property in event loop to delay it a bit in earlier versions of the
> > patch, I also tried replacing blocking wait for more bytes with
> > event loop based approach, none of which helped.  
> 
> I doubt it's the X server. More likely, it's GNOME itself. Is the X
> root window provided by a specific process in the desktop, or does it
> just exist? If it's the former, it might be GNOME's fault.

It just exist. Always exist. Even if you don't have a WM running.

> It would be worth checking if Gtk-4 has the same issue.
> 
> But I still can't explain why XInternAtom would block. You'd need to
> get a backtrace of the X.org process to see if it is blocked. What
> does it mean to intern an atom? Does it send something to the root
> window to register it?

As far as I understand it just registers a string as an integer ID
referred to as atom. So it's apparently just some string-integer map
inside X server.

https://tronche.com/gui/x/xlib/window-information/properties-and-atoms.html

> For efficiency reasons, an atom is used rather than a character
> string. XInternAtom() can be used to obtain the atom for property
> names.

> Also... X.org isn't being actively developed any more. KDE Plasma
> Workspace 6 has made it nigh impossible to use X with High DPI (it
> might be Qt's fault), which is again something that your patch
> affects and is affected by. Is it still worth trying to patch X11 for
> more High DPI? Or just throw the towel and use Wayland?

Well, the point here is to ensure the cursor is updated when the
settings affecting it appearance change. As migrating from Xcursor to
xcb-cursor made it impossible to set custom cursor theme name from
settings sources Qt reads.

By the way, high DPI works ok for me on Plasma 6 with both X11 and
Wayland.

> > Although I remember that Liang Qi once reproduced it only with
> > `-sanitize address` (while it was ok without it for him, too). So
> > perhaps there's a chance ASAN breaks poll() in some way? And I guess
> > it's possible nothing will help then...  
> 
> Unlikely. The most likely scenario is that XInternAtom() didn't get a
> reply because no reply was sent. So under what conditions would there
> be no reply to that operation?

I don't really see any other reason than X server being deadlocked on
something. Which is very weird.

> Looking at your patch again, you've added code that reacts to an 
> XCB_PROPERTY_NOTIFY, which is the the same thing that GDK is getting
> stuck on.

Yeah. Given that the event loop is in GTK code, it means it either
successfully handled the event in Qt code or haven't got to it yet.
None of which really explain the hang (other than a possibility of
triggering some bug inside X server).