Version: 3.2.1 (using KDE KDE 3.4.1) Installed from: Fedora RPMs OS: Linux Whenever I open a large C++ file in KDevelop (with KWrite as an editor), KDevelop hangs the instant I try to close the tab with that file open. By large C++ file, I mean about 15,000 lines of code (453KB). I can open the file just fine, I can also edit and save the file without any problems, but 100% of the time when I attempt to close the file, KDevelop goes into an infinite loop, eating 99.9% of my CPU for as long as my patience can tolerate (I then kill it). The exact same file can be opened and closed in KWrite without it hanging, so I don't think the problem resides in KWrite.
I have exactly the same problem. It seems that after attempting to close the file the memory usage (along with CPU) increases rapidly.
Same trouble here. I have played a bit with ksysguard, it seems that KDevelop is really aggressive with the memory allocation, a lot more than Openoffice. However I saw that I can open and close with no problem a really big file (10 MByte) with Kdevelop but only if there is no project opened. When I try to close the same file when a project is loaded... Nov 6 01:01:44 tom_lap kernel: Total swap = 525128kB Nov 6 01:01:44 tom_lap kernel: Out of Memory: Killed process 5077 (kdevelop). Hope this hepls
Here some other info have captured about this fault: running "strace kdevelop" I saw: [...] project and big file loaded... NB: file size is 9.081.973 read(13, "", 4096) = 0 fstat64(13, {st_mode=S_IFREG|0664, st_size=9081973, ...}) = 0 fstat64(13, {st_mode=S_IFREG|0664, st_size=9081973, ...}) = 0 [here I closed the file] close(13) = 0 munmap(0xb4477000, 4096) = 0 stat64(".", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 getcwd("/home/tom1/src/src_cdr/parser", 4096) = 30 stat64(".", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 getcwd("/home/tom1/src/src_cdr/parser", 4096) = 30 gettimeofday({1133575484, 750474}, NULL) = 0 clock_gettime(CLOCK_REALTIME, {1133575484, 750682000}) = 0 futex(0xbfec5cb4, FUTEX_WAKE, 1) = 0 mmap2(NULL, 25169920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb2c77000 gettimeofday({1133575484, 841555}, NULL) = 0 clock_gettime(CLOCK_REALTIME, {1133575484, 841845000}) = 0 futex(0xbfec5cb4, FUTEX_WAKE, 1) = 0 gettimeofday({1133575484, 896829}, NULL) = 0 etc etc.... NB: size of each mmap is 25.169.920 ?? then I tried with gdb: #0 0xb6abf2cc in memcpy () from /lib/tls/libc.so.6 #1 0xb7235976 in QString::setLength () from /usr/lib/qt3/lib/libqt-mt.so.3 #2 0xb7235af1 in QString::grow () from /usr/lib/qt3/lib/libqt-mt.so.3 #3 0xb7235cf1 in QString::insert () from /usr/lib/qt3/lib/libqt-mt.so.3 #4 0xb7235d9c in QString::insert () from /usr/lib/qt3/lib/libqt-mt.so.3 #5 0xb530eff1 in Lexer::nextToken () from /usr/lib/libkdevcppparser.so.0 #6 0xb5311c09 in Lexer::tokenize () from /usr/lib/libkdevcppparser.so.0 #7 0xb5311de0 in Lexer::setSource () from /usr/lib/libkdevcppparser.so.0 #8 0xb5306ef9 in Driver::parseFile () from /usr/lib/libkdevcppparser.so.0 #9 0xb5402631 in BackgroundParser::parseFile () from /usr/lib/kde3/libkdevcppsupport.so *************look here - start************** #10 0xb5402aa8 in BackgroundParser::problems () from /usr/lib/kde3/libkdevcppsupport.so #11 0xb5401495 in ProblemReporter::closedFile () from /usr/lib/kde3/libkdevcppsupport.so *************look here-end****************** #12 0xb54016bb in ProblemReporter::qt_invoke () from /usr/lib/kde3/libkdevcppsupport.so #13 0xb6eecf6f in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #14 0xb7e5eaaa in KDevPartController::closedFile () from /usr/lib/libkdevelop.so.1 #15 0xb7ef8f9a in PartController::closePart () from /usr/lib/libkdevshell.so.0 #16 0xb7ef4f18 in PartController::slotCloseWindow () from /usr/lib/libkdevshell.so.0 #17 0xb7efaf0f in PartController::qt_invoke () from /usr/lib/libkdevshell.so.0 #18 0xb6eed009 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #19 0xb6eed538 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #20 0xb7896729 in KAction::activated () from /usr/lib/libkdeui.so.4 #21 0xb78d0385 in KAction::qt_emit () from /usr/lib/libkdeui.so.4 #22 0xb6eed042 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0xb6eed538 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #24 0xb729398a in QButton::clicked () from /usr/lib/qt3/lib/libqt-mt.so.3 #25 0xb6f9ac1c in QButton::mouseReleaseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #26 0xb6f31337 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #27 0xb6e7fec0 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb6e80ee1 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb767d35e in KApplication::notify () from /usr/lib/libkdecore.so.4 #30 0xb6e0de3b in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0xb6e0c667 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #32 0xb6e228d8 in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0xb6e99e29 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0xb6e99d24 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0xb6e7f71c in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 well, it would be nice to know why when a file has been closed it is necessary to parse it to report a problem... here the source code: void ProblemReporter::closedFile(const KURL &fileName) { QValueList<Problem> problems = m_cppSupport->backgroundParser()->problems( fileName.path() , true , true); } Tom
Seams like yet another cpp-parser issue.
Some move observations. I am runign Suse 10, KDE 3.4.2 Level B, Kdevelop 3.2.2 First of all, the problem occurs no matter if I am using the "Embedded advanced editor" or the "QT Designer based editor" This is some output I noticed in the terminal window from which I ran kdevelop: terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc KCrash: Application 'kdevelop' crashing...
*** This bug has been confirmed by popular vote. ***
Please find here some other discussion made on the mail about this fault: http://barney.cs.uni-potsdam.de/mailman/private/kdevelop-devel/2005-December/034339.html
Is this reproducible on current 3.4 SVN? The problems view is now a plain widget and will not make any decisions about when to parse.
I stared at this again, at there shouldn't be a way for this to happen now, as the file isn't parsed on close now. Assuming fixed.
On Tuesday 09 January 2007 02:32, Jens Dagerbo wrote: [bugs.kde.org quoted mail] After a few tests I can confirm you the fault is fixed. I made the test with a 46MB text file. kdevelop is now quick in opening it (some secs) but still slow in closing (tenth of secs). Running kdevelop from gdb I saw where that time is spent: gdb) bt #0 0x499325a0 in ?? () from /lib/i686/libc.so.6 #1 0x499815a1 in mallopt () from /lib/i686/libc.so.6 #2 0x49981f23 in free () from /lib/i686/libc.so.6 #3 0x44bc6cc1 in operator delete () from /usr/lib/libstdc++.so.6 #4 0x49307cf4 in QStringData::deleteSelf () from /usr/lib/qt3/lib/libqt-mt.so.3 #5 0x4e45a915 in Lexer::nextToken () from /usr/lib/libkdevcppparser.so.0 #6 0x4e45fef4 in Lexer::tokenize () from /usr/lib/libkdevcppparser.so.0 #7 0x4e460126 in Lexer::setSource () from /usr/lib/libkdevcppparser.so.0 #8 0x4e46033a in Driver::parseFile () from /usr/lib/libkdevcppparser.so.0 #9 0x49e16c9a in BackgroundParser::parseFile () from /usr/lib/kde3/libkdevcppsupport.so #10 0x49e17622 in BackgroundParser::problems () from /usr/lib/kde3/libkdevcppsupport.so #11 0x49e176a8 in ProblemReporter::closedFile () from /usr/lib/kde3/libkdevcppsupport.so #12 0x49e200c4 in ProblemReporter::qt_invoke () from /usr/lib/kde3/libkdevcppsupport.so #13 0x4903ffb1 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #14 0xb7eb72a5 in KDevPartController::closedFile (this=0x81183d8, t0=@0xbff1bc50) at kdevpartcontroller.moc:147 #15 0xb7f60afe in PartController::closePart (this=0x81183d8, part=0x9237d38) at partcontroller.cpp:815 #16 0xb7f5ceb5 in PartController::slotCloseWindow (this=0x81183d8) at partcontroller.cpp:932 [...] and about 20 secs later: #0 0x4e457e82 in Lexer::nextToken () from /usr/lib/libkdevcppparser.so.0 #1 0x4e45fef4 in Lexer::tokenize () from /usr/lib/libkdevcppparser.so.0 #2 0x4e460126 in Lexer::setSource () from /usr/lib/libkdevcppparser.so.0 #3 0x4e46033a in Driver::parseFile () from /usr/lib/libkdevcppparser.so.0 #4 0x49e16c9a in BackgroundParser::parseFile () from /usr/lib/kde3/libkdevcppsupport.so #5 0x49e17622 in BackgroundParser::problems () from /usr/lib/kde3/libkdevcppsupport.so #6 0x49e176a8 in ProblemReporter::closedFile () from /usr/lib/kde3/libkdevcppsupport.so [...] related code is: problemreporter.cpp ln 272 void ProblemReporter::closedFile(const KURL &fileName) { QValueList<Problem> problems = m_cppSupport->backgroundParser()->problems( fileName.path() , true , true); } and in backgroundparser.cpp ln 332: QValueList<Problem> BackgroundParser::problems( const QString& fileName, bool readFromDisk, bool forceParse ) { Unit * u = findUnit( fileName ); if ( u == 0 || forceParse ) { m_fileList->remove ( fileName ); u = parseFile( fileName, readFromDisk ); } return u ? u->problems : QValueList<Problem>(); } Closedfile is calling BackgroundParser::problems with readfromdisk=true and forceParse=true, so that the file is reread and parsed again when kdevelop is closing it. This behavoir sounds strange to me, but this is not related to bug 113379. Thanks a lot Tom
I was of course referring to latest 3.4 branch. Your stacktrace suggest you are running 3.3 or an earlier 3.4 snapshot - the ProblemReporter::closedFile() method doesn't even exist anymore.
Corect, I was using 3.5 branch. Yesterday I have switched to branch 3.4, rebuilt kdevelop and tested again. I was able to open a 64MB file in a few seconds and close it in half time.... wonderful job!!!
Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively