luebking wrote:did you attempt to run "kbuildsycoca --noincremental" (it seems unlikely that a different issue leads to the same conditions/backtraces)

Sadly this doesn't help either

In the commit page you mention, its been fixed in 2011, KDE version 4.6.1.
I'm pretty sure my whole system has been installed well after that.
Will try too the steps and see if solves.

The "problem" is that the bug fits the backtraces - KMimeType (unsupposingly) returns a nullptr and the commit fixed such occasion. Lasted commits to KMimeType have been 2013, so any remotely recent KDE should either be "fixed" or suffer from the same problem.

There might still be another bug in this context, leading to the same result (but I didn't spot code prone to this at a glimpse)

What's your exact version of kdecore?

Code: Select all

ldd `which kwrite`| grep kdecore


luebking wrote:What's your exact version of kdecore?

Code: Select all

ldd `which kwrite`| grep kdecore


The result of this command is

Code: Select all

libkdecore.so.5 => /usr/lib/libkdecore.so.5 (0x00007efed5235000)


But each time i run this command the last hex number changes.

Ciao,
Rainer

The hex change is ok, but why does kdecore only resolve a major?

/usr/lib/libkdecore.so.5 should be a symbolic link to something like /usr/lib/libkdecore.so.5.11.8

If there's no problem in that regard (eg. you're keeping an old version of libkdecore around) you'd need to check the kdelibs verision by "kde4-config --version" (and if ldd resolves the same libkdecore for kde4-config, it's the version of kwrite as well)

/usr/lib/libkdecore.so.5 is a symlink to /usr/lib/libkdecore.so.5.14.2

And "kde4-config --version" gives

Code: Select all

Qt: 4.8.7
KDE: 4.14.2
kde4-config: 1.0