Bug 352854

Summary: KService 5.14.2 turn on kbuildsycoca5 and Plasma slow down
Product: [Frameworks and Libraries] frameworks-kservice Reporter: Davide Marcelli <davide.marcelli>
Component: generalAssignee: David Faure <faure>
Status: RESOLVED FIXED    
Severity: crash CC: arojas, awilfox, bastian.beischer, dr.scient, felixonmars, heiko.becker, hrvoje.senjan, jan_braun, kdelibs-bugs, kwpolska, nirvandil, paolo.pedroni, pereira.alex, rdieter, sachslgc, simonandric5, waltercool, zeekec
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:

Description Davide Marcelli 2015-09-17 19:08:18 UTC
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
Comment 1 Pablo Cholaky 2015-09-18 00:11:18 UTC
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.
Comment 2 Pablo Cholaky 2015-09-18 00:16:58 UTC
This issue seems very related to this commit https://quickgit.kde.org/?p=kservice.git&a=commit&h=0a719bb93110d125adb0218b3f9bfbe567851ae7
Comment 3 A. Wilcox (awilfox) 2015-09-18 00:38:43 UTC
This looks like a duplicate of bug 352787 to me.
Comment 4 Antonio Rojas 2015-09-18 07:11:25 UTC
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.
Comment 5 David Faure 2015-09-18 07:15:30 UTC
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?
Comment 6 David Faure 2015-09-18 07:20:23 UTC
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,
Comment 7 Bastian Beischer 2015-09-18 09:11:23 UTC
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.
Comment 8 Nirvandil 2015-09-18 11:51:50 UTC
I can confirm this issue on 2 machines running Gentoo ~adm64. Upgraded from
kservice-5.14.0, saw lagging and masked 5.14.2.
Comment 9 David Faure 2015-09-18 12:15:09 UTC
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.
Comment 10 Nirvandil 2015-09-18 16:06:28 UTC
>> 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...
Comment 11 Antonio Rojas 2015-09-18 21:06:15 UTC
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
Comment 12 Oleg Höfling 2015-09-19 07:27:02 UTC
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.
Comment 13 David Faure 2015-09-19 08:38:17 UTC
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.
Comment 14 Antonio Rojas 2015-09-19 08:48:58 UTC
No, the patch doesn't fix it
Comment 15 David Faure 2015-09-19 08:50:26 UTC
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?
Comment 16 Antonio Rojas 2015-09-19 09:04:11 UTC
The new patch works, no more kbuilsycoca loop
Comment 17 Alexandre Pereira 2015-09-19 12:34:39 UTC
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 ).
Comment 18 Jan-Matthias Braun 2015-09-19 12:39:22 UTC
Hurray! Works like a charm. Had the same problem and the patch works.

Thanks a lot!
Comment 19 Alexandre Pereira 2015-09-19 12:44:29 UTC
forgot to mention on comment #17, between restart after git kservice, i reenabled kbuildsycoca5
Comment 20 David Faure 2015-09-19 14:55:49 UTC
Thanks for the testing guys. 5.14.3 is tagged, unittest added, and 5.15 will be more robust anyway.
Comment 21 David Faure 2015-09-20 17:34:30 UTC
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