Misbehavior when unloading KStyle

[Andreas Hartmetz]

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 at 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 :)