Version: (using KDE KDE 3.4.1) Installed from: Gentoo Packages I tried to compare $KDEDIR/share with .kde/share. This is the reproducible result: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1944)] [KCrash handler] #5 0x417209f1 in kill () from /lib/libc.so.6 #6 0x4166b8c0 in pthread_kill () from /lib/libpthread.so.0 #7 0x4166bc9b in raise () from /lib/libpthread.so.0 #8 0x41720466 in raise () from /lib/libc.so.6 #9 0x41721e1a in abort () from /lib/libc.so.6 #10 0x400c08eb in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #11 0x400be525 in __cxxabiv1::__terminate () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #12 0x400be562 in std::terminate () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #13 0x400be6d2 in __cxa_throw () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #14 0x400be92f in operator new () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #15 0x400be9dd in operator new[] () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #16 0x411e6c42 in QString::setLength () from /usr/qt/3/lib/libqt-mt.so.3 #17 0x411e70a0 in QString::grow () from /usr/qt/3/lib/libqt-mt.so.3 #18 0x411e8ac5 in QString::operator+= () from /usr/qt/3/lib/libqt-mt.so.3 #19 0x41d02c29 in KompareProcess::slotReceivedStdout (this=0xffffc96, buffer=0x0, length=0) at kompareprocess.cpp:224 #20 0x41d030a6 in KompareProcess::qt_invoke (this=0x82edc18, _id=-1073750752, _o=0xbfffdc90) at kompareprocess.moc:114 #21 0x40f009b4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #22 0x40a5b9cf in KProcess::receivedStdout (this=0x82edc18, t0=0x0, t1=0x0, t2=0) at kprocess.moc:152 #23 0x40a5ba9f in KProcess::childOutput (this=0x82edc18, fdno=1097280388) at kprocess.cpp:852 #24 0x40a5bad9 in KProcess::slotChildOutput (this=0x82edc18, fdno=0) at kprocess.cpp:732 #25 0x40a5bdf2 in KProcess::qt_invoke (this=0x82edc18, _id=2, _o=0xbfffe240) at kprocess.moc:201 #26 0x41d0302e in KompareProcess::qt_invoke (this=0x82edc18, _id=2, _o=0xbfffe240) at kompareprocess.moc:118 #27 0x40f009b4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #28 0x40f00f7a in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #29 0x412539e0 in QSocketNotifier::activated () from /usr/qt/3/lib/libqt-mt.so.3 #30 0x40f1d53f in QSocketNotifier::event () from /usr/qt/3/lib/libqt-mt.so.3 #31 0x40e9dd6f in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #32 0x40e9df0c in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #33 0x40a17505 in KApplication::notify (this=0xbfffe9c0, receiver=0x82de340, event=0xbfffe670) at kapplication.cpp:549 #34 0x40e91663 in QEventLoop::activateSocketNotifiers () from /usr/qt/3/lib/libqt-mt.so.3 #35 0x40e49501 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #36 0x40eb4470 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #37 0x40eb43c6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #38 0x40e9cf1f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #39 0x080559fd in main (argc=0, argv=0x0) at main.cpp:213
Interesting.. Just how big was this diff? the backtrace implies that you ran out of memory whilst storing the diff output - i.e the comparison generated a diff larger than the amount of RAM you have. This is the interesting bit: #15 0x400be9dd in operator new[] () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 #16 0x411e6c42 in QString::setLength () from /usr/qt/3/lib/libqt-mt.so.3 #17 0x411e70a0 in QString::grow () from /usr/qt/3/lib/libqt-mt.so.3 #18 0x411e8ac5 in QString::operator+= () from /usr/qt/3/lib/libqt-mt.so.3 You said the comparison was between $KDEDIR/share and .kde/share.. could you please run "diff -u $KDEDIR/share .kde/share | wc" to find out how big the diff was? - Jeff
Not -u, but -ur: 15107 42863 650785 You're right, the used memory goes up to several hundred megabytes and grabs all free resident memory. Since this box has only 256MB + 2GB swap... Is this a memleak or does kompare keep such diffs entirely in the memory?
Just tried the same with $KDEDIR/share/apps. Kompare needed a while, but didn't crash. It used up to 1 GB virtual and 200 MB pyhsical memory. Slightly excessive. :)
in fact, not -ur, but -uNr :P (the N includes new and/or deleted files in the diff) Since the set of files in the two dirs will differ in this case quite a lot, it's likely to be far larger than those 650785 bytes... can you run again? apologes for the bad command - Jeff
.. and when I said "quite a lot", i meant it - I just ran this on my system, and it was 75k with -ur and 80Mb with -uNr.
I know where it comes from, it is the inline differences, they are not deleted since I use it to also show the differences in the string. Those tables are not deleted somehow and that is where the excessive memory use comes from. There is another bug afaik that is open regarding this.
Bruggie: I was almost ready to close this as a dupe of #90345, but if you examine the backtrace, the crash is in KProcess::slotRecievedStdout, which happens before the parser and the levenstein tables. #90345 is a partial explanation for comment #3, but it doesn't explain the original backtrace
Right I will see if I have some time to analyze this further then.
This is gonna be a little spammy... I'm reassigning everything that's currently assigned to bruggie (who's been the default assignee for bugs since time began) to the new list address. Bruggie: if you're working on one or more of these atm, please snatch 'em back.. Everyone, esp. Joshua and Bruggie: if this genrates 33 mails, my sincere apologies..
*** Bug 112401 has been marked as a duplicate of this bug. ***
This crash is from the KDE 3 version, which is no longer maintained. If you are experience crashes with the KDE 4 version, please attach an updated backtrace or report a new bug.