On Tuesday 14 May 2024 07:30:01 GMT-7 Ilya Fedin wrote: > I have a long standing (1.5 years) problem with > https://codereview.qt-project.org/c/qt/qtbase/+/427313 that the CI > hangs on so-called "cmptest". Previously the CI just reported that > timeout has happened and I had no idea what exactly happened. > Asking reviewers to get a backtrace to see where it hangs led to radio > silence. Good news is that the CI became better on this in those 1.5 > years and gives the following backtrace at least: >
Thread 1 (Thread 0x7fe3fe4e78c0 (LWP 12267) "tst_qsettings"): #0 0x00007fe4015d8bcf in __GI___poll (fds=0x7ffe5b94bdc8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fe4004f07e2 in () at /lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007fe4004f0eb1 in () at /lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007fe4004f1ea6 in xcb_wait_for_reply64 () at /lib/x86_64-linux-gnu/ libxcb.so.1 #4 0x00007fe40136931c in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6 #5 0x00007fe40134e888 in XInternAtom () at /lib/x86_64-linux-gnu/libX11.so.6 #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 #11 0x00007fe3fc6e2f46 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #12 0x00007fe40123ed3b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/ libglib-2.0.so.0 #13 0x00007fe401294258 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x00007fe40123c3e3 in g_main_context_iteration () at /lib/x86_64-linux- gnu/libglib-2.0.so.0 #15 0x00007fe401fd2bd0 in TestNamespace::QEventDispatcherGlib::processEvents(TestNamespace::QFlags<TestNamespace::QEventLoop::ProcessEventsFlag>) (this=0x55b7c0350c90, flags=...) at /home/qt/work/qt/qtbase/src/corelib/kernel/ qeventdispatcher_glib.cpp:395 #16 0x00007fe3fd38b9aa in TestNamespace::QXcbGlibEventDispatcher::processEvents(TestNamespace::QFlags<TestNamespace::QEventLoop::ProcessEventsFlag>) (this=0x55b7c0350c90, flags=...) at /home/qt/work/qt/qtbase/src/plugins/ platforms/xcb/qxcbeventdispatcher.cpp:96 #17 0x00007fe401b5436c in TestNamespace::QCoreApplication::processEvents(TestNamespace::QFlags<TestNamespace::QEventLoop::ProcessEventsFlag>, TestNamespace::QDeadlineTimer) (flags=..., deadline=...) at /home/qt/work/qt/ qtbase/src/corelib/kernel/qcoreapplication.cpp:1435 #18 0x00007fe401c17e09 in TestNamespace::QTest::qWait(std::chrono::duration<long, std::ratio<1l, 1000l> >) (msecs=...) at /home/qt/work/qt/qtbase/src/corelib/kernel/ qtestsupport_core.cpp:127 #19 0x00007fe401c17d6d in TestNamespace::QTest::qWait(int) (msecs=50) at / home/qt/work/qt/qtbase/src/corelib/kernel/qtestsupport_core.cpp:94 > Still, this backtrace doesn't have debug symbols and doesn't really > help. Can I get a better backtrace from the CI somehow, with debug > symbols for glib, gtk3, Xlib and xcb? Who and how should I contact for > that? It *does* have debug symbols... for Qt. The problem is that it's getting stuck inside of libxcb and gdk (glib), which come from the OS. I don't know what gdk is doing, but it's stalled at gdk_x11_atom_to_xatom_for_display trying to XInternAtom. If I were to make a wild guess, it's trying to get something from a process, but that process is itself and because it's on a blocking call, it can't reply. I do note the XCB event handler thread is free, so you should check if your changes are allowing whichever reply this is to come from that separate thread. The above isn't cmptest. It's tst_qsettings. But you can see other tests having the same problem too, like tst_qguichronotimer. -- 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
