Summary: | crash on diff of larger directory trees | ||
---|---|---|---|
Product: | [Applications] kompare | Reporter: | Carsten Lohrke <carstenlohrke> |
Component: | general | Assignee: | Kompare developers <kompare-devel> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | crash | CC: | cfeck, esigra, wsf |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Carsten Lohrke
2005-06-03 15:21:27 UTC
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. |