After the upgrade from kservice 5.13 to 5.14.2, Plasma crashes and start to become very slow, 2-3 seconds for every operation and the cpu warm up. I noticed that this latest version of kservice start continuously kbuildsycoca5, without the possibility of kill it. A downgrade resolved the problem. Reproducible: Always
I can confirm this issue. Same problem happens, kbuildsycoca5 is spamming and doing plasma unusable. downgrading kservice from 5.14.2 to 5.14.0 fixes currently the issue. Tested with Gentoo.
This issue seems very related to this commit https://quickgit.kde.org/?p=kservice.git&a=commit&h=0a719bb93110d125adb0218b3f9bfbe567851ae7
This looks like a duplicate of bug 352787 to me.
After some experiments; I've checked that this only happens when upgrading directly 5.14.0 -> 5.14.2. Upgrading 5.14.0 -> 5.14.1 and then 5.14.1 -> 5.14.2 works correctly.
What is extremely confusing to me, is that I made the 5.14.2 release of kservice to fix bug 352787 which had very similar symptoms to this one. So the two bugs are the opposite of each other.... the commit *fixed* the same problem for the reporter of bug 352787, while for you guys it seems to have *introduced* the problem. Very confusing. Is there any chance that someone with a debug build could run kbuildsycoca5 in gdb and put a breakpoint on KSycocaPrivate::buildSycoca(), and give me the backtrace if it's indeed called?
Ah, when you say upgrade, I suppose you mean, inside a running session. That would explain it. 5.13 -> 5.14 had an incompatible change in the binary format on disk. So an old running app could run the upgraded kbuildsycoca5, try to read the result, declare it corrupted, run kbuildsycoca5 again, etc. 5.14 -> 5.14.1 reverts the file format change, but that means this is another incompatible change right there. So the same can happen. But it should stop after logout + login, because then all programs should be using the same version of the code, and the rebuilt DB should be declared valid by all readers. If my theory is correct then 1) a direct 5.13 -> 5.14.2 upgrade should be smooth 2) logout and login should fix the issue, after upgrading to 5.14.2. If I'm wrong, then there is another bug,
Assuming kservice 5.14.2 is good the following should also work, right?: - log out of KDE - make sure no KDE related processes are running anymore - remove the ~/.cache/ksycoca5* files - upgrade to kservice 5.14.2 - restart kde Because it does not: kbuildsycoca5 keeps restarting infinitely with high CPU use.
I can confirm this issue on 2 machines running Gentoo ~adm64. Upgraded from kservice-5.14.0, saw lagging and masked 5.14.2.
OK so clearly there's another bug. Anyone up for attaching full-debug logs, and/or for using gdb to find out who is calling KSycocaPrivate::buildSycoca()? (either from inside kbuildsycoca5, or possibly this is done by another process, if not kbuildsycoca) Otherwise I'll debug this during the weekend.
>> Anyone up for attaching full-debug logs, and/or for using gdb to find out who is calling KSycocaPrivate::buildSycoca()? (either from inside kbuildsycoca5, or possibly this is done by another process, if not kbuildsycoca) I have lot of time to this, but I don't know how to do it...
It's plasmashell that is triggering this. Killing plasmashell stops the kbuildsycoca loop. Backtrace: #0 0x00007ffff13dcefc in pselect () from /usr/lib/libc.so.6 #1 0x00007ffff1d0e83a in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/libQt5Core.so.5 #2 0x00007ffff1d0e9e8 in ?? () from /usr/lib/libQt5Core.so.5 #3 0x00007ffff1c51f49 in ?? () from /usr/lib/libQt5Core.so.5 #4 0x00007ffff1becbbf in QProcess::waitForFinished(int) () from /usr/lib/libQt5Core.so.5 #5 0x00007ffff44b399e in KSycocaPrivate::buildSycoca (this=this@entry=0x7d4950, ifNotFound=..., ifNotFound@entry=...) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycoca.cpp:592 #6 0x00007ffff44b40dd in KSycocaPrivate::checkDirectories (this=this@entry=0x7d4950, ifNotFound=..., ifNotFound@entry=...) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycoca.cpp:577 #7 0x00007ffff44b452f in KSycocaPrivate::checkDatabase (this=0x7d4950, ifNotFound=ifNotFound@entry=...) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycoca.cpp:432 #8 0x00007ffff44b45bd in KSycoca::findFactory (this=0x77e1e0, id=id@entry=KST_KMimeTypeFactory) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycoca.cpp:452 #9 0x00007ffff44b872b in KSycocaFactory::KSycocaFactory (this=0x6cf3810, factory_id=KST_KMimeTypeFactory, sycoca=<optimized out>) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycocafactory.cpp:53 #10 0x00007ffff4483f96 in KMimeTypeFactory::KMimeTypeFactory (this=0x6cf3810, db=<optimized out>) at /build/kservice/src/kservice-5.14.2/src/services/kmimetypefactory.cpp:30 #11 0x00007ffff448414d in KSycocaFactorySingleton<KMimeTypeFactory>::self (this=<optimized out>) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycocafactory_p.h:223 #12 KMimeTypeFactory::self () at /build/kservice/src/kservice-5.14.2/src/services/kmimetypefactory.cpp:48 #13 0x00007ffff4485ddd in mimeTypeSycocaServiceOffers (mimeType=...) at /build/kservice/src/kservice-5.14.2/src/services/kmimetypetrader.cpp:103 #14 KMimeTypeTrader::query (this=<optimized out>, mimeType=..., genericServiceType=..., constraint=...) at /build/kservice/src/kservice-5.14.2/src/services/kmimetypetrader.cpp:176 #15 0x00007fffef80e627 in KFileItemActions::associatedApplications(QStringList const&, QString const&) () from /usr/lib/libKF5KIOWidgets.so.5 #16 0x00007ffff6155632 in ?? () from /usr/lib/libKF5Plasma.so.5 #17 0x00007ffff6153b2e in ?? () from /usr/lib/libKF5Plasma.so.5 #18 0x00007ffff1ceafea in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #19 0x00007ffff44b1951 in KSycoca::notifyDatabaseChanged (this=0x77e1e0, changeList=...) at /build/kservice/src/kservice-5.14.2/src/sycoca/ksycoca.cpp:367 #20 0x00007ffff44c40a5 in KSycoca::qt_metacall (this=0x77e1e0, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0x7fffffffde50) at /build/kservice/src/build/src/moc_ksycoca.cpp:129 #21 0x00007ffff2aa1293 in ?? () from /usr/lib/libQt5DBus.so.5 #22 0x00007ffff1cebeb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #23 0x00007ffff308b00c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #24 0x00007ffff30904e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #25 0x00007ffff1cbc89b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 ---Type <return> to continue, or q <return> to quit--- #26 0x00007ffff1cbec96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #27 0x00007ffff1d12e33 in ?? () from /usr/lib/libQt5Core.so.5 #28 0x00007fffed88e9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #29 0x00007fffed88ece0 in ?? () from /usr/lib/libglib-2.0.so.0 #30 0x00007fffed88ed8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #31 0x00007ffff1d1323f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #32 0x00007ffff1cba26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #33 0x00007ffff1cc220c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #34 0x00000000004300f3 in main () Let me know if you need a new bt with more debug symbols
I also can confirm this. To reproduce, I open Application Launcher and switch to Applications. The all applications list becomes greyed out, and a message "Applications updated" is drawn. Once the Applications tab is opened, the high cpu/io load starts.
I logged into a KF5 desktop and couldn't reproduce the bug for some reason, but I spotted a bug in the v5.14.2 commit. A wrong cast would mess up the timestamp, so it's logical that apps would keep thinking the sycoca is too old and needs to be rebuilt. Can you guys apply this patch to kservice, make install, and restart the session? http://www.davidfaure.fr/2015/kbuildsycoca.diff If this fixes it I'll make a 5.14.3 ... BTW kservice.git master should also work fine already, since all this has been redone there for the better.
No, the patch doesn't fix it
I sucked and uploaded a wrong version of the patch first (with only one line changes) then replaced it with a fixed version (with two line changes). You were faster than I thought ;) Sorry, can you try again with the updated patch?
The new patch works, no more kbuilsycoca loop
I can confirm: Today i updated gentoo box kservice to kservice-5.14.2 ( from 5.14.0 ) and was experiencing this. Also noted that in dolphin, image thumbnails were always generated ( not using cache ). Also, menu launchers were always saying "new apps updated (in portuguese)". upon reading this bugreport, I chmod -x /usr/bin/kbuildsycoca5 and things were imediatly faster. Then i installed kservice from git ( kservice-9999 ) in gentoo, restarted and all was well ( also dolphin thumbnails cache ).
Hurray! Works like a charm. Had the same problem and the patch works. Thanks a lot!
forgot to mention on comment #17, between restart after git kservice, i reenabled kbuildsycoca5
Thanks for the testing guys. 5.14.3 is tagged, unittest added, and 5.15 will be more robust anyway.
Git commit 051588c9d990d96b787b22dd586f6ec654f02ee3 by David Faure. Committed on 20/09/2015 at 10:26. Pushed by dfaure into branch 'master'. Add unittest for the timestamp check, so that bug 352854 doesn't happen again. M +2 -0 autotests/ksycocatest.cpp http://commits.kde.org/kservice/051588c9d990d96b787b22dd586f6ec654f02ee3