On Fri, Apr 8, 2016 at 3:42 PM, Andreas Hartmetz <ahartm...@gmail.com> wrote: > On Donnerstag, 7. April 2016 20:33:19 CEST Andreas Hartmetz wrote: >> 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/qxc >> > b >> > connection.cpp:1321 #4 0x00007ffff14ae2f9 in QThreadPrivate::start >> > (arg=0xe54730) at >> > /home/apol/devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_un >> > i >> > 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. >> > > https://bugreports.qt.io/browse/QTBUG-52473 > > Good place to add any additional useful information :)
The bug report Martin pointed out leads here: https://bugreports.qt.io/browse/QTBUG-51648 Is it the same? Aleix _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
