Short story: KSycoca is not thread safe, reentrant or anything else that might make it usable in a multithreaded application. This is true of many parts of kdelibs, actually. Well, guess what krunner does? Yep, run lots and lots of threads.
Between the runners themselves we share a "kdelibs lock" that prevents one runner from entering these sensitive bits of kdelibs while others are.
Unfortunately, the startup info is also in there and .. guess what .. uses KSycoca. So every once in a while, when things line up juuuuust right, a runner is (with the lock) fetching data from KSycoca when we get an appliation startup notification and *poof* there goes krunner.
I triggered this bug today, generated a backtrace and then, stupidity of stupidity, accidentally closed the backtrace window! Oh no! I need the backtrace to see exactly where in the startup feedback machinery we're hitting this problem so I can then track down the problems with accuracy (versus just guessing, even if my guesses are sometimes right).
Since this is not the easiest crash in the world trigger and I'd like to not spend an entire day sitting there trying to egg it out of krunner again, I'm asking all of you who are running KDE from svn trunk to help me out here: if you manage to crash krunner and you get a backtrace that starts out in KSycoca stuff and then trails back into krunner symbols that contain the word "startup" in them, please save that backtrace and mail it to me.
Thank you very much in advance! =)
p.s. and yes, while it would make lots of sense to make more paths in kdleibs, such as some of the KSycoca stuff, at least reentrant, that's a ton of work that I don't have time for right now. Especially not before 4.1 ;)