Bug 113379

Summary: KDevelop hangs when closing very large files
Product: [Applications] kdevelop Reporter: Fred <FredericDruide>
Component: Language Support: CPP (old)Assignee: kdevelop-bugs-null
Status: RESOLVED FIXED    
Severity: crash    
Priority: NOR    
Version: 3.2.1   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Fred 2005-09-26 20:31:13 UTC 
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.
Comment 1 Dima Batenkov 2005-10-09 22:31:15 UTC 
I have exactly the same problem. It seems that after attempting to close the file the memory usage (along with CPU) increases rapidly.
Comment 2 Tom Max 2005-11-06 01:25:18 UTC 
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
Comment 3 Tom Max 2005-12-03 04:29:33 UTC 
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
Comment 4 Amilcar do Carmo Lucas 2005-12-06 17:28:18 UTC 
Seams like yet another cpp-parser issue.
Comment 5 Steve Hartmann 2006-01-26 18:28:05 UTC 
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...
Comment 6 Daniel Schmitt 2006-03-09 14:00:26 UTC 
*** This bug has been confirmed by popular vote. ***
Comment 7 Tom Max 2006-03-09 14:39:11 UTC 
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
Comment 8 Jens Dagerbo 2007-01-01 15:35:28 UTC 
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.
Comment 9 Jens Dagerbo 2007-01-09 02:32:12 UTC 
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.
Comment 10 Tom Max 2007-01-17 09:44:18 UTC 
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
Comment 11 Jens Dagerbo 2007-01-17 19:09:38 UTC 
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.
Comment 12 Tom Max 2007-01-26 10:33:10 UTC 
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!!!
Comment 13 Aleix Pol 2013-03-31 00:53:49 UTC 
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