Review Request 127261: Fix dead lock when program use kauth exits.

[Xuetian Weng]

> On March 3, 2016, 7:05 a.m., Martin Gräßlin wrote:
> > nice work! I had run into it in the past and didn't succeed investigating it.
> 
> Xuetian Weng wrote:
>     https://bugreports.qt.io/browse/QTBUG-51648
>     
>     As pointed out by Thiago on irc, this should be considered as a bug in Qt. Not sure if we want to commit it. As disconnecting this signal indeed breaks some invariant in qtdbus (not critical though, since we are going to exit anyway).
> 
> Martin Gräßlin wrote:
>     Let's wait then whether Qt 5.6 comes with it fixed or not.

Well, Thiago said there's no time to fix it before 5.6.0 though.


- Xuetian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127261/#review93082
-----------------------------------------------------------


On March 2, 2016, 8:58 p.m., Xuetian Weng wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127261/
> -----------------------------------------------------------
> 
> (Updated March 2, 2016, 8:58 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: kauth
> 
> 
> Description
> -------
> 
> I'm on Qt 5.6 RC, and just notice a issue that kded5 never cleanly exits.
> 
> With gdb attached to kded5, it shows following backtrace:
> 
>     #1  0x00007ffff5c820eb in QWaitConditionPrivate::wait (time=18446744073709551615, this=0x74ac70) at thread/qwaitcondition_unix.cpp:136
>     #2  QWaitCondition::wait (this=this at entry=0x71c308, mutex=mutex at entry=0x71c300, time=time at entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:208
>     #3  0x00007ffff5c7b08b in QSemaphore::acquire (this=this at entry=0x7fffffffd840, n=n at entry=1) at thread/qsemaphore.cpp:137
>     #4  0x00007ffff5e80fff in QMetaObject::activate (sender=sender at entry=0x976280, signalOffset=<optimized out>, local_signal_index=local_signal_index at entry=0, argv=argv at entry=0x7fffffffd8d0)
>         at kernel/qobject.cpp:3698
>     #5  0x00007ffff5e81687 in QMetaObject::activate (sender=sender at entry=0x976280, m=m at entry=0x7ffff6092760 <QObject::staticMetaObject>, local_signal_index=local_signal_index at entry=0, 
>         argv=argv at entry=0x7fffffffd8d0) at kernel/qobject.cpp:3595
>     #6  0x00007ffff5e8172f in QObject::destroyed (this=this at entry=0x976280, _t1=_t1 at entry=0x976280) at .moc/moc_qobject.cpp:213
>     #7  0x00007ffff5e886e5 in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:913
>     #8  0x00007fffb39bbb09 in KAuth::DBusHelperProxy::~DBusHelperProxy (this=0x976280, __in_chrg=<optimized out>) at /chakra/core/kauth/src/kauth-5.19.0/src/backends/dbus/DBusHelperProxy.cpp:55
>     #9  0x00007ffff5e49ff9 in QLibraryPrivate::unload (this=0x71dba0, flag=QLibraryPrivate::NoUnloadSys) at plugin/qlibrary.cpp:551
>     #10 0x00007ffff5e4e521 in QLibraryStore::cleanup () at plugin/qlibrary.cpp:397
>     #11 0x00007ffff78592ef in __cxa_finalize () from /usr/lib/libc.so.6
>     #12 0x00007ffff5c52583 in __do_global_dtors_aux () from /usr/lib/libQt5Core.so.5
>     #13 0x00007fffffffe230 in ?? ()
>     #14 0x00007ffff7dea867 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
> 
> 
> Which indicates that kauth dbus plugin's QObject::destroyed is being connected to QDBusConnectionPrivate with Qt::BlockQueuedConnection. But at this point, QApplication is already gone and this call is never being handled. Disconnect everything in destructor can fix this issue.
> 
> Related upstream qt code:
> https://github.com/qtproject/qtbase/blob/5.6.0/src/dbus/qdbusintegrator.cpp#L2135
> 
> 
> Diffs
> -----
> 
>   src/backends/dbus/DBusHelperProxy.cpp 20dad0a 
> 
> Diff: https://git.reviewboard.kde.org/r/127261/diff/
> 
> 
> Testing
> -------
> 
> Now kded5 can exits upon logout/exit. Tested with kquitapp5 kded5.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160304/44c8a45b/attachment-0001.html>