Version: 1.6.4 (using KDE 3.5.3 Level "a" , SUSE 10.1.1) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.16.20-2-smp Konsole crashes after some output, for example ls on home directory a couple of times. My OS is SuSE 10.2 Alpha 2. On Alpha 1, there was no problem. When I asked this on opensuse maillist, they told that Alpha 2 is compiled using more intelligent memory management library. Therefore I run the program with kde-debug-info and kdebase-debug-info of SuSE 10.2 Alpha 2 under valgrind. I don't like to put the log file here, since it is too long, but here is the summary: ==5632== LEAK SUMMARY: ==5632== definitely lost: 865 bytes in 26 blocks. ==5632== indirectly lost: 11,201 bytes in 42 blocks. ==5632== possibly lost: 3,072 bytes in 1 blocks. ==5632== still reachable: 297,896 bytes in 7,419 blocks. ==5632== suppressed: 0 bytes in 0 blocks. ==5632== Reachable blocks (those to which a pointer was found) are not shown. ==5632== To see them, rerun with: --show-reachable=yes --5632-- memcheck: sanity checks: 1845 cheap, 74 expensive --5632-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --5632-- memcheck: auxmaps: 0 searches, 0 comparisons --5632-- memcheck: SMs: n_issued = 296 (4736k, 4M) --5632-- memcheck: SMs: n_deissued = 3 (48k, 0M) --5632-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --5632-- memcheck: SMs: max_undefined = 0 (0k, 0M) --5632-- memcheck: SMs: max_defined = 403 (6448k, 6M) --5632-- memcheck: SMs: max_non_DSM = 293 (4688k, 4M) --5632-- memcheck: max sec V bit nodes: 171187 (8693k, 8M) --5632-- memcheck: set_sec_vbits8 calls: 1713618 (new: 203158, updates: 1510460) --5632-- memcheck: max shadow mem size: 13685k, 13M --5632-- translate: fast SP updates identified: 93,461 ( 90.1%) --5632-- translate: generic_known SP updates identified: 6,129 ( 5.9%) --5632-- translate: generic_unknown SP updates identified: 4,028 ( 3.8%) --5632-- tt/tc: 1,561,240 tt lookups requiring 4,597,944 probes --5632-- tt/tc: 1,561,240 fast-cache updates, 15 flushes --5632-- transtab: new 75,283 (1,597,734 -> 25,133,031; ratio 157:10) [0 scs] --5632-- transtab: dumped 0 (0 -> ??) --5632-- transtab: discarded 1,878 (42,503 -> ??) --5632-- scheduler: 184,539,634 jumps (bb entries). --5632-- scheduler: 1,845/3,230,708 major/minor sched events. --5632-- sanity: 1846 cheap, 74 expensive checks. --5632-- exectx: 30,011 lists, 41,707 contexts (avg 1 per list) --5632-- exectx: 1,241,050 searches, 1,231,967 full compares (992 per 1000) --5632-- exectx: 137,411 cmp2, 270 cmp4, 0 cmpAll
The interesting part is this: ==5691== 230 errors in context 6 of 6: ==5691== Invalid read of size 2 ==5691== at 0x50CA680: QLatin15Codec::toUnicode(char const*, int) const (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x50C8529: QTextStatelessDecoder::toUnicode(char const*, int) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x409A653: TEmulation::onRcvBlock(char const*, int) (TEmulation.cpp:332) ==5691== by 0x40A11B8: TESession::onRcvBlock(char const*, int) (session.cpp:746) ==5691== by 0x40AB6F9: TESession::qt_invoke(int, QUObject*) (session.moc:462) ==5691== by 0x4DCFD3C: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x4085F37: TEPty::block_in(char const*, int) (TEPty.moc:143) ==5691== by 0x408606A: TEPty::dataReceived(KProcess*, char*, int) (TEPty.cpp:233) ==5691== by 0x408DF32: TEPty::qt_invoke(int, QUObject*) (TEPty.moc:164) ==5691== by 0x4DCFD3C: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x49CEEED: KProcess::receivedStdout(KProcess*, char*, int) (kprocess.moc:152) ==5691== by 0x49CEFC7: KProcess::childOutput(int) (kprocess.cpp:853) ==5691== Address 0x6899924 is 0 bytes after a block of size 4 alloc'd ==5691== at 0x40217E9: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5691== by 0x509FFEC: (within /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x50A12B1: QString::fromLatin1(char const*, int) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x50CA66A: QLatin15Codec::toUnicode(char const*, int) const (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x50C8529: QTextStatelessDecoder::toUnicode(char const*, int) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x409A653: TEmulation::onRcvBlock(char const*, int) (TEmulation.cpp:332) ==5691== by 0x40A11B8: TESession::onRcvBlock(char const*, int) (session.cpp:746) ==5691== by 0x40AB6F9: TESession::qt_invoke(int, QUObject*) (session.moc:462) ==5691== by 0x4DCFD3C: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.6) ==5691== by 0x4085F37: TEPty::block_in(char const*, int) (TEPty.moc:143) ==5691== by 0x408606A: TEPty::dataReceived(KProcess*, char*, int) (TEPty.cpp:233) ==5691== by 0x408DF32: TEPty::qt_invoke(int, QUObject*) (TEPty.moc:164)
this looks a bit like a Qt bug actually, but as I can't reproduce this with my home dir I'm lost
It has something to do with the international settings. Being from Finland, I use LC_ALL="fi_FI@euro" settings. If I set it to LC_ALL="c", no crashing happends. But when I set it back to "fi_FI@euro", konsole crashes after some "ls" commands. It might be, that I have some files that have scandinavian letters on their names, but I remember konsole crashing on other programs also, where I think no Latin-9 letters were shown.
Hello Arto, Does it matter which directories you run 'ls' on (when LC_ALL is set to "fi_FI@euro" )? - particularly I am interested in the result when running ls on a directory which definitely does have files with Scandinavian letters in their names versus a directory which has only files with plain ASCII letters in their names.
Robert Knight wrote: [bugs.kde.org quoted mail] I have not seen the problem for some time (I have now OpenSUSE 10.2), so I assumed the problem went away on some newer KDE. When I had the problem, it did not matter (I try not to use Scandinavian letters on my filenames since programs have problems with names that do not use USASCII letters) what letters the file had. After some pages of ls listing, the konsole crashed. -- Arto Viitanen
I think I have seen this reported elsewhere, it would seem to be a Qt issue.