Misbehavior when unloading KStyle

[Andreas Hartmetz]

On Freitag, 8. April 2016 17:25:06 CEST Aleix Pol wrote:
> On Fri, Apr 8, 2016 at 3:42 PM, Andreas Hartmetz <ahartmetz at 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 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 :)
> 
> The bug report Martin pointed out leads here:
> https://bugreports.qt.io/browse/QTBUG-51648
> 
> Is it the same?
> 
Oh yes, indeed, and it has been fixed by now, too.