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

[David Faure]

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


Fix it, then Ship it!




Please push asap, I'm releasing today.


src/backends/dbus/DBusHelperProxy.cpp (line 55)
<https://git.reviewboard.kde.org/r/127261/#comment63536>

    add a comment here, point to the Qt bug report, maybe even put this in a QT_VERSION ifdef, all so that this workaround doesn't get forgotten, and gets cleaned up instead.


- David Faure


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/20160305/f1510b18/attachment.html>