Bug 96909 - kdevelop consumes all memory and locks up X when loading file
Summary: kdevelop consumes all memory and locks up X when loading file
Status: RESOLVED DUPLICATE of bug 78978
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (show other bugs)
Version: 3.1.2
Platform: Gentoo Packages Linux
: NOR crash with 82 votes (vote)
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
: 85878 97492 99501 99502 100588 100857 109466 109609 109833 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-13 13:25 UTC by Darke
Modified: 2013-03-31 00:46 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Attachment that causes kdevelop to consume all memory (13.29 KB, application/x-bzip2)
2005-01-13 13:26 UTC, Darke
Details
Another testcase (get.c from Mesa source code) (12.11 KB, application/x-bzip2)
2005-01-22 14:48 UTC, Nicolai Haehnle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darke 2005-01-13 13:25:22 UTC
Version:           3.1.2 (using KDE KDE 3.3.2)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)
 
OS:                Linux

Upon adding a particular file (generated by python's c++ interface stuff), to a generic c++ project.

Steps are in ideal mode:

* Click on 'file tree' left tab
* Locate file in directory hierachy.
* Right click and select 'add X to project'

kdevelop will then instantly jump to around 500Meg memory usage (up from around 30meg), and rapidly increase to within 30-45 seconds where it will consume all availble memory on this machine (1Gig + 1Gig swap), and lock everything up.

The file that causes this problem will be attached momentarialy, and this should be able to be repdocuced by simply adding it to a new project.

This resembles the bugs ID95040 and ID78978 but this is on an AthlonXP system, rather then A64.

Nothing interesting happens when I run kdevelop from a terminal, no filenames or other data are dumped before it starts consuming all available memory.
Comment 1 Darke 2005-01-13 13:26:31 UTC
Created attachment 9068 [details]
Attachment that causes kdevelop to consume all memory
Comment 2 Nicolai Haehnle 2005-01-22 14:48:56 UTC
Created attachment 9217 [details]
Another testcase (get.c from Mesa source code)

Attached another testcase with the exact same behaviour the original poster
described.

While trying to figure out what the hell was going wrong with KDevelop, I
noticed that the parser generally eats an *insane* amount of memory. It's not
unusual for the memory consumption to rapidly jump from around 50MB to 300+MB
while parsing one file, then freeing all this memory again. It seems likely
that this behaviour is related to the lockup that happens with the attached
testcases - the problem is simply more severe with the testcases than with
other files.
Comment 3 Jens Dagerbo 2005-01-22 15:19:18 UTC
I'm afraid you might be right.. I looked at one other testcase we got sent, a 9000+ lines file of SWIG-generated C++ code. I loaded the file in KDevelop and breaked it in gdb. I could see nothing obviously wrong, the parser went its merry way, it had just gobbled up about 1GB of RAM (so far).

Unfortunately, a rewritten parser is probably at least a year away, so for the time being I don't think we have a solution.

A remedy could be to create a file named ".kdev_ignore" in the directory of the file that makes the parser go nuts. This should make it disregard the contents of this directory.
Comment 4 Stephen Rhodes 2005-02-01 15:17:12 UTC
I have been struggling with this bug ever since kedevelop3 hit the streets. I have a pair of files containing many hundreds of template specializations. I am happy to confirm that the fix described above completely cures the problem. 
Comment 5 Jens Dagerbo 2005-02-03 01:25:22 UTC
*** Bug 97492 has been marked as a duplicate of this bug. ***
Comment 6 Jens Dagerbo 2005-02-03 01:26:31 UTC
*** Bug 85878 has been marked as a duplicate of this bug. ***
Comment 7 Thiago 2005-02-12 03:59:54 UTC
I have the same problem here. If I use the ".kdev_ignore" solution and open the "problem file" after the project is loaded, then kdevelop consumes all memory and gets killed by oom-killer when I try to close the file.

The files are from Doom3 SDK:

Simd.cpp 4113 lines 
glext.h 5922 lines
Comment 8 Oliver Batchelor 2005-02-16 20:27:40 UTC
I reverted to the old pre-3.0 beta at once stage to avoid this bug - it only seems to be the stable releases which have this issue.
Comment 9 Stephan Heigl 2005-02-16 20:30:32 UTC
Oliver Batchelor wrote:

>------- You are receiving this mail because: -------
>You are on the CC list for the bug, or are watching someone who is.
>         
>http://bugs.kde.org/show_bug.cgi?id=96909         
>
>
>
>
>------- Additional Comments From owb13 student canterbury ac nz  2005-02-16 20:27 -------
>I reverted to the old pre-3.0 beta at once stage to avoid this bug - it only seems to be the stable releases which have this issue.
>
>
>  
>

Comment 10 Stephan Heigl 2005-02-16 20:32:50 UTC
Oliver Batchelor wrote:

>------- You are receiving this mail because: -------
>You are on the CC list for the bug, or are watching someone who is.
>         
>http://bugs.kde.org/show_bug.cgi?id=96909         
>
>
>
>
>------- Additional Comments From owb13 student canterbury ac nz  2005-02-16 20:27 -------
>I reverted to the old pre-3.0 beta at once stage to avoid this bug - it only seems to be the stable releases which have this issue.
>
>
>  
>
Thank you very much for that info. Perhaps it gets fixed some time. I 
havent tried it we more recent version since i filed this report. 
Perhaps its fixed. (sorry for the empty response before)

Comment 11 Jens Dagerbo 2005-02-17 00:25:33 UTC
Interesting.. can you please specify what pre-3.0 beta release this was?
Comment 12 Jens Dagerbo 2005-02-17 00:27:33 UTC
*** Bug 99501 has been marked as a duplicate of this bug. ***
Comment 13 Jens Dagerbo 2005-02-17 00:28:45 UTC
*** Bug 99502 has been marked as a duplicate of this bug. ***
Comment 14 Oliver Batchelor 2005-02-17 01:10:39 UTC
Unfortunately I can't be sure - I have an old directory lying around which is  2003-11-28 which looks like one I was using.
Comment 15 Stephen Rhodes 2005-02-22 15:43:48 UTC
Although using the .kdev_ignore allows my projects to load without this problem occurring, if one of the problem files gets opened in the environment (say with a debugger trace) it is impossible to close it without the system seizing up.

Incidently the files that give a problem in my case are very heavily nested set of template specializations which one would never want to see in the class browser - they just clog it up. Some kind of gui switch (setting a .kdev_ignore file?) to prevent the parser descending into selected directories would be very nice, even if we didn't have this snag.

Stephen

Stephen
Comment 16 Jens Dagerbo 2005-03-02 13:28:11 UTC
*** Bug 100588 has been marked as a duplicate of this bug. ***
Comment 17 Jens Dagerbo 2005-03-07 10:19:47 UTC
*** Bug 100857 has been marked as a duplicate of this bug. ***
Comment 18 Jens Dagerbo 2005-07-25 22:31:09 UTC
*** Bug 109609 has been marked as a duplicate of this bug. ***
Comment 19 Jens Dagerbo 2005-07-25 22:32:26 UTC
*** Bug 109466 has been marked as a duplicate of this bug. ***
Comment 20 Jens Dagerbo 2005-07-30 11:54:29 UTC
*** Bug 109833 has been marked as a duplicate of this bug. ***
Comment 21 Jens Dagerbo 2005-07-30 11:55:52 UTC
Note: bug #109833 contains reproductions steps.
Comment 22 Maciej Dems 2006-01-18 11:51:36 UTC
I have also noticed this bug when parsing SWIG-generated cpp.

If fixing parser is really that hard thing I would suggest the elegant workaround. If the file .kdev_ignore has actually any content, consider it as the list of files to ingore (i.e. one per line). This way one could remove the problematic file from parsing while letting the others to be still parsed.
Comment 23 Przemyslaw Bruski 2006-04-27 22:10:17 UTC
Try this patch:
http://bruscy.multicon.pl/pages/przemek/patches/kdevelop3.diff
Comment 24 Jens Dagerbo 2006-05-01 22:31:10 UTC
Marking as dupe.

*** This bug has been marked as a duplicate of 78978 ***
Comment 25 Johannes Ballé 2006-10-10 17:57:46 UTC
Confirming this bug for kdevelop versions 3.3.2 and 3.3.4 on KDE 3.5.2 on a Gentoo box. The culprit is h264.c from ffmpeg/libavcodec (~ 8000 lines).

Recompiling with patch above (applied without problems). Will post results later.
Comment 26 Aleix Pol 2013-03-31 00:46:33 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