luebking wrote:can you run

Code: Select all

kcmshell4 filetypes

(without having it crash and check (filter!) the configuration for "text/plain"?

Yeah i can, pretty standard, txt files, applications : kwrite, kate, emacs, okular,
Service is 'embedded advanced text editor' (katepart), okulartxt,
default settings for konqueror......

I opens pretty much most stuff, except some specific files, for example a empty text file created with dolphin... ( but also some others which is the case why it matters)

Hi,

i know this is a quite old thread but it seems that the problem still exists in current distributions. A friend of mine who uses the new kde 5 version doesn't seem to have the problem. So it seems that this bug was fixed in newer versions. Is there any workaround to fix this problem for the still often used kde 4 version?

I use Debian Testing and have KDE 4.14.2 installed. Kate is 3.14.2 with kate component 3.7 and kwrite 4.14.2 which bases on the same kate component. Both crash when opening newly created files in dolphin or some other text files. I found out that it has to do with the beginning byte in the text file. Newly created text files in dolphin doesn't start empty (why not??) instead they have the two bytes 0x20 0x0A which is a space and newline. When i delete these characters kate/kwrite can open this file without crashing. Also Text files starting with any ascii number from 0-9 seems to cause the crash. When the file starts witch ascii a-z it could be normally opened. That's quite weired for an texteditor to be so specific for the first byte in the file but it is always reproducible to crash these two programs.

Ciao,
Rainer

Sure it's the *same* crash (with a similar backtrace ending in sycoca?)

It rather smells like a crash caused by the encoding detection (got a backtrace?)
=> settings|open/save|encoding detection: disabled
Still crashes?

luebking wrote:Sure it's the *same* crash (with a similar backtrace ending in sycoca?)

It rather smells like a crash caused by the encoding detection (got a backtrace?)
=> settings|open/save|encoding detection: disabled
Still crashes?

I tried disabling the encoding detection but the result is the same.

The backtrace (without debug packages installed) from the "kde crash handler" program also has one line with KSycocaEntry in it.

Code: Select all

Application: Kate (kate), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f03911d1880 (LWP 17338))]

Thread 3 (Thread 0x7f037bf4f700 (LWP 17339)):
#0  0x00007f038e09608f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f037d8128ea in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x00007f037d812919 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x00007f038e0920a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x00007f0390b4704d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f02fa09d700 (LWP 17340)):
#0  0x00007f0390b402b3 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f038e952daf in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007f038e86c86f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007f038e0920a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x00007f0390b4704d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f03911d1880 (LWP 17338)):
[KCrash Handler]
#6  0x00007f038fa8bc41 in KSycocaEntry::name() const () from /usr/lib/libkdecore.so.5
#7  0x00007f037de277d2 in Kate::TextBuffer::load(QString const&, bool&, bool&, bool) () from /usr/lib/libkatepartinterfaces.so.4
#8  0x00007f037dea049e in KateBuffer::openFile(QString const&, bool) () from /usr/lib/libkatepartinterfaces.so.4
#9  0x00007f037de95b3f in KateDocument::openFile() () from /usr/lib/libkatepartinterfaces.so.4
#10 0x00007f038af3573a in ?? () from /usr/lib/libkparts.so.4
#11 0x00007f038af37b76 in KParts::ReadOnlyPart::openUrl(KUrl const&) () from /usr/lib/libkparts.so.4
#12 0x00007f037de80dde in KateDocument::openUrl(KUrl const&) () from /usr/lib/libkatepartinterfaces.so.4
#13 0x00007f038f62b047 in ?? () from /usr/lib/libkateinterfaces.so.4
#14 0x00007f038f62b4ec in ?? () from /usr/lib/libkateinterfaces.so.4
#15 0x00007f038f63a971 in ?? () from /usr/lib/libkateinterfaces.so.4
#16 0x00007f038f622f29 in KateApp::startupKate() () from /usr/lib/libkateinterfaces.so.4
#17 0x00007f038f623e35 in KateApp::initKate() () from /usr/lib/libkateinterfaces.so.4
#18 0x00007f038f624230 in KateApp::KateApp(KCmdLineArgs*) () from /usr/lib/libkateinterfaces.so.4
#19 0x00007f0390e0f7fc in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kate.so
#20 0x00007f0390a82b45 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x00000000004006fe in _start ()


Ciao,
Rainer

Cheers, still happens to me too... For some reason KDE packages in debian have been frozen to the dark ages
Same deal here, if I create an empty text file through dolphin kpart crashes, but if I open with another text editor, for example nano, and clear out the file, kwrite opens it.
But I still don't know how to fix already filled files.

It's the same backtrace as the OP - and likely some stack corruption.
TextBuffer::load() does not call to KSycoca::name() - see http://lxr.kde.org/source/kde/applicati ... stable-qt4

This is indeed during the encoding detection, but the loop is entered *once* regardless of the setting (so it won't help)

The only reference to a "name" symbol I could spot is QTextCodec::name(), which is invoked in certain debug calls.
=> run "kdebugdialog" and ensure everything that says "kate" (and notably id 13020) is disabled, but if this is indeed some stack corruption, the error is somewhere else => valgrind.

gfurst wrote:But I still don't know how to fix already filled files.

The only "fix" i know is to edit these files to start with any normal alphabet character (a-z) and no space or number. Than i can open them without problems.

But it is sad to know that this bug seems to be fixed in newer kde versions and there is no backport of whatever the problem is to the versions debian is using in their latest stable os version.

In the kde bugtracker exist two bugs specific to this problem:
https://bugs.kde.org/show_bug.cgi?id=345189
https://bugs.kde.org/show_bug.cgi?id=348977

But until today nobody seems to take note of these bugs.

Ciao,
Rainer

Very good - those bugs have better backtraces.

The problem is the TextLoader instantiation, which apparently tries to resolve

m_mimeType = KMimeType::findByPath (filename, 0, false)->name ();

(what means the file cannot be opened for reading???)

KMimeType::findByPath however returns "NULL" - this was apparently fixed by
http://quickgit.kde.org/?p=kdelibs.git& ... ad6ecb1d1d

=> delete ~/.local/share/mime/globs (or check it for invalid entries by hand

=> delete ~/.local/share/mime/globs (or check it for invalid entries by hand

Should this be the trick to avoid the program crashing?
I tried deleting the glob (and glob2) file but this doen't change the crashing behaviour of kate/kwrite when opening text files with "bad" starting byte.
Or do i have to reboot because the file is maybe cached or something else?

Ciao,
Rainer

I'm actually not 100% sure how this is handled.

delete it, then run "update-mime-database" and ultimately "kbuildsycoca" or "kbuildsycoca4" - try again and hope for the best, but it could still be that the bogus glob entry is recreated automatically, then you're screwed

PS: I've also a glob2 file - I assume it's rewritten with update-mime-database, but be aware of it.

"update-mime-database" wants a "MIME-DIR" directory as parameter, but which should this be?
I tried as user

Code: Select all

update-mime-database /usr/share/mime

but had no permission. Than i tried as root and it run ok but no new glob file in ~/.local/share/mime/ for root nor the user.

Ciao,
Rainer

Code: Select all

update-mime-database ~/ .local/share/mime


Ok that created both files (globs and globs2) new but it also doesn't change the crashing behaviour.

But thanks for all your help so far. I really appreciate it.

Ciao,
Rainer

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