Ouch ouch ouch.

Can you
export QT_MESSAGE_PATTERN='%{appname}(%{pid})/%{category} %{function}: %{message}'
so that debug output indicates which process outputs each line?

I'll try going back in time (to KF 5.13,  then back to 5.14) with kservice to see if I can reproduce this.

Please make a backup of /home/hrvoje/.cache/ksycoca5 before deleting it (which is the workaround). But without a backup we'll never know if the upgrade bug is fixed.

I'll try dowgrading to 5.13 tommorow so i can repeat the process. Please note that after initial post upgrade crash, things seem to run fine.

I can't trigger the crash in my test (which is admittedly just downgrading kservice, removing ksycoca5, running kbuildsycoca5 (-> version 300), upgrading kservice again, running kbuildsycoca5... which says this, as expected:

kbuildsycoca5 running...
kbuildsycoca5(5760)/kf5.kservice.sycoca KSycocaPrivate::openDatabase: Trying to open ksycoca from "/home/dfaure/.cache/ksycoca5"
kbuildsycoca5(5760)/kf5.kservice.sycoca KSycocaPrivate::checkVersion: Found version 300 , expecting version 302 or higher.
kbuildsycoca5(5760)/kf5.kservice.sycoca KSycocaPrivate::checkVersion: Found version 300 , expecting version 302 or higher.
kbuildsycoca5(5760)/default KBuildSycoca::recreate: Recreating ksycoca file ("/home/dfaure/.cache/ksycoca5", version 302)
(and it proceeds as usual)

I also tried not running kbuildsycoca5 myself but letting an app trigger it (after reverting to a copy of the v300 sycoca), no crash.
Not denying there's a bug of course, but either
- I'm not testing this correctly, or
- the incompatibility only happens with specific data in the db (so no matter what I try it won't happen here), or
- the bug only happens on a specific architecture (is this x86_64 ?)

d46be24c9fb583183cefabec045a7a4b93c714a1 is the obvious suspect commit. I changed the QDataStream serialization version, but the sycoca version increase is supposed to force a rebuild before reading the old data with the new serialization version... I also changed a 32 bit int to 64 bit, but only in the ksycoca5-timestamp file which isn't really used.

The interesting bt would be the one from "ERROR: KSycoca database corruption!" .... i.e. maybe put an abort() in KSycoca::flagError(), to get a core dump of how we get there....

Note: I had the corruption error when *downgrading* kservice.

I think I understand what's happening then. If someone logs out, upgrades, logs in, it should all be fine.
But if someone upgrades kservice while plasma5 is running, the new kbuildsycoca5 will generate a v302 db which existing apps will try to read with v300 code, and break.

Usually when we extend the db, we do so in a way so that old apps can read the new db (and skip over the stuff they don't know). My datastream versioning change doesn't do that, unfortunately.
I can revert that for now (I'm changing filenames soon anyway, which will be the right opportunity for it).
http://www.davidfaure.fr/2015/revert_format_change.diff

If this works for you, I'll make a 5.14.1 tarball for kservice.

David, the diff seems to be empty...
I've tried changing the version to Qt_3_1 by hand (plus bumping ksyscoca version), xsession still reports the corruption in ~/.xsession-errors-:0, though now kdeinit5 doesn't crash...

Ooops, I made a local commit and then git diff > file. Doh.

Now the link to the diff should work.
And yes this isn't just changing the datastream version but also going back to a uint32 (in seconds) instead of a uint64 (in ms) for the timestamp field.

Ok, now newTimestamp is left undeclared ;-)

So things are working fine it seems with this patch (sed 's/newTimestamp/m_newTimestamp/'). No corruption mentioned, no crash, so a ship it from me =)

This was a patch for v5.14.0, it applies and compiles there. Were you trying to apply it to git master maybe? Otherwise I don't understand the compilation problem you had.

(In reply to David Faure from comment #9)
> This was a patch for v5.14.0, it applies and compiles there. Were you trying
> to apply it to git master maybe? 
Yep

Fixed in 5.14.1.

Not yet fixed in git master, I'd rather switch to a different filename soon than apply this.

I'm seeing something similar with 5.19.0. Did the mentioned patch make it into master?

$ kbuildsycoca5 --version
kbuildsycoca5 5.19.0
$ kbuildsycoca5 --noincremental --global
kbuildsycoca5 running...
kbuildsycoca5(3331)/default unknown: Recreating ksycoca file ("/home/oever/.local/share/ksycoca/ksycoca5_en", version 303)
kbuildsycoca5(3331)/default unknown: Menu "applications-kmenuedit.menu" not found.
kbuildsycoca5(3331)/default unknown: Saving
$ kcminit
kcminit(3336)/kf5.kservice.sycoca unknown: ERROR: KSycoca database corruption!
kcminit(3336)/kf5.kservice.sycoca unknown: ERROR: KSycoca database corruption!
kcminit(3336)/kf5.kservice.sycoca unknown: ERROR: KSycoca database corruption!
kcminit(3336)/kf5.kservice.sycoca unknown: ERROR: KSycoca database corruption!
kcminit(3336)/default unknown: Recreating ksycoca file ("/home/oever/.cache/ksycoca5_en_ZDaXpKg+fqgYRYEHHfhMEXeSCyc=", version 303)
kcminit(3336)/default unknown: Menu "applications-kmenuedit.menu" not found.
kcminit(3336)/default unknown: Saving
kcminit(3336)/kf5.kservice.sycoca unknown: ERROR: KSycoca database corruption!
kcminit(3336)/default unknown: Initializing  "kded_touchpad" :  "kcminit_touchpad"
kcminit(3336)/default unknown: Width:  3852  height:  3046
kcminit(3336)/default unknown: Approx. resX:  42  resY:  60
kcminit(3336)/default unknown: Touchpad resolution: x:  53  y:  55
kcminit(3336)/default unknown: Final resolution x: 53  y: 55
kcminit(3336)/default unknown: Initializing  "kcm_style" :  "kcminit_style"
kcminit(3336)/default unknown: QFile::copy: Empty or null file name
kcminit(3336)/default unknown: Initializing  "kcm_input" :  "kcminit_mouse"
kcminit(3336)/default unknown: Initializing  "kcm_access" :  "kcminit_access"