On Wed, 15 May 2024 07:33:11 -0700 Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Wednesday 15 May 2024 03:12:26 GMT-7 Ilya Fedin wrote: > > > 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. > > Also note that other tests ran fine after these deadlocked. So if the > X server had had a major bug, we should be seeing everything after > this test failing. > > It's possible the bug does exist, just causing the reply to get > dropped for this connection. But as it's that simple an > implementation as you say, it isn't likely. I guess the actual code in Xorg might be more complicated than needed given that it had a problem with having a maintainer... > > 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). > > You said that GDK is using a different libxcb and libX11 connection > from Qt. That means the Qt XCB code could not handle event sent to > GDK nor vice-versa. Yeah, it makes the problem only more weird... -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
