Misbehavior when unloading KStyle

[Aleix Pol]

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?

Aleix