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

[Thiago Macieira]

On Tuesday 14 May 2024 13:24:12 GMT-7 Ilya Fedin wrote:
> On Tue, 14 May 2024 12:59:29 -0700
> 
> Thiago Macieira <thiago.macieira at intel.com> wrote:
> > Assuming that Canonical did not patch libgdk,
> 
> Well, that is a very optimistic assumption:
> http://archive.ubuntu.com/ubuntu/pool/main/g/gtk+3.0/gtk+3.0_3.24.33-1ubuntu
> 2.1.debian.tar.xz
> 
> I see 24 pathes in there.

Do any of them affect gdkeventsource.c? I don't see any.

> > this is stuck trying to
> > XInternAtom for "_GTK_EDGE_CONSTRAINTS", reacting to an xevent of
> > type PropertyNotify.
> > https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/x11/gdkdisplay-x11.
> > c#L1068
> > 
> > I can't tell you why it's stuck. Why would the X server not send a
> > reply to that?
> 
> I don't know any reason for _GTK_EDGE_CONSTRAINTS exactly but generally
> I saw reports X11 deliberately not answering to clients using GLX when
> on another tty. 

Yes, I remember that and have experienced the symptom. AFAIU, you're slightly 
mistaken in the actual root cause: it's not the X11 server deliberately not 
answering. The X.org server is frozen too, because the KMS driver in the 
kernel refuses to answer.

> 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 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?

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?

> 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?

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240514/8167204a/attachment-0001.bin>