On Mittwoch, 6. April 2016 20:10:53 CEST Aleix Pol wrote: > Hi, > I've seen a couple of times such backtrace [1] which shows Qt waiting > for something that never happens. An easy way to reproduce is to load > konversation (or any application with KDBusService::Unique), hide it > and run it again. The exit call will never be fulfilled in the second > process. > > Any idea of what could be the cause of this? Or why it's happening? > > Regards, > Aleix > > [1] https://paste.kde.org/pstps66fj > [2] (gdb) thread 2 > [Switching to thread 2 (Thread 0x7fffe180f700 (LWP 10000))] > #0 0x00007ffff08a3c3d in poll () from /usr/lib/libc.so.6 > (gdb) where > #0 0x00007ffff08a3c3d in poll () from /usr/lib/libc.so.6 > #1 0x00007fffedb4fae2 in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007fffedb51757 in xcb_wait_for_event () from > /usr/lib/libxcb.so.1 #3 0x00007fffe513b269 in QXcbEventReader::run > (this=0xe54730) at > /home/apol/devel/frameworks/qt5/qtbase/src/plugins/platforms/xcb/qxcb > connection.cpp:1321 #4 0x00007ffff14ae2f9 in QThreadPrivate::start > (arg=0xe54730) at > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_uni > x.cpp:340 #5 0x00007fffee827424 in start_thread () from > /usr/lib/libpthread.so.0 #6 0x00007ffff08accbd in clone () from > /usr/lib/libc.so.6 > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
I've seen this happening as well. It looks it's triggered by a certain destruction order of global statics (as in Q_GLOBAL_STATIC) and involves a QObject::destroyed() (not sure about that one) signal sent to the (new in 5.6) DBus thread (aka QDBusConnectionManager) which is moveToThread(Q_NULLPTR)-ed into some kind of limbo state when shutting down because its global static container is destroyed, where it stops event processing. The connection is a BlockingQueuedConnection, so it hangs indefinitely. If you have your environment set up in a way that Qt applications use a KStyle, you only need a main function consisting of QApplication(argc, argv); exit(EXIT_SUCCESS /* doesn't matter */); to trigger it. Note: you should not exit() with a QApplication around, it's asking for problems anyway. kactivitmanagerd does it extensively and hangs very reliably currently... I have a request to change this on Phabricator. Note 2: you should NEVER try to handle signals by calling QApplication::quit() to exit cleanly. That is very much not something that's safe to do in a signal context. I have seen this in two different KDE daemons so far. I've talked to Thiago about the apparent Qt bug. He said he'd get to it next week and so I haven't filed a bug yet. I'm still planning to do that. Cheers, Andreas _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel