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.macie...@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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
