On Tuesday 14 May 2024 11:44:24 GMT-7 Thiago Macieira wrote: > 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.
Backtrack from what you know: It's stuck inside XInternAtom waiting for a reply from the server. That means it's trying to get some information about an atom. It's stuck, meaning this must be a deadlock, which must be happening because the event is looping back to this application and that isn't responding. You don't have debugging symbols in the CI VMs, but you can get them locally. Get a VM or container using Ubuntu 22.04 and, with a little bit effort you can undo the address space randomisation and find out the unknown frame addresses based on the known ones: #6 0x00007fe3fc6e93d8 in gdk_x11_atom_to_xatom_for_display () at /lib/x86_64- linux-gnu/libgdk-3.so.0 #7 0x00007fe3fc6ddc29 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #8 0x00007fe3fc6df191 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #9 0x00007fe3fc6e2d28 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #10 0x00007fe3fc6a8a99 in gdk_display_get_event () at /lib/x86_64-linux-gnu/ libgdk-3.so.0 You know 0x00007fe3fc6a8a99 is in gdk_display_get_event(), so you should be able to deduce the base address libgdk got loaded at, and therefore recalculate which functions those three middle ones are. You can ask one of the Qt Company developers "acquire a VM" and get a core dump for this test's hang. You can then load the core dump in your VM/ container and see what the state of GDK was. Searching GDK 3.x sources, the most likely reason for that is information about the clipboard/selection status. -- 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
