Misbehavior when unloading KStyle

[Andreas Hartmetz]

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 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.

Cheers,
Andreas