Review Request 127261: Fix dead lock when program use kauth exits.
Martin Gräßlin
mgraesslin at kde.org
Thu Mar 3 07:05:10 UTC 2016
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127261/#review93082
-----------------------------------------------------------
Ship it!
nice work! I had run into it in the past and didn't succeed investigating it.
- Martin Gräßlin
On March 2, 2016, 9: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, 9: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/20160303/d775a5c3/attachment.html>
More information about the Kde-frameworks-devel
mailing list