| Summary: | kdevelop consumes all memory and locks up X when loading file | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Darke <darkepaw> |
| Component: | Language Support: CPP (old) | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | doll, espinosa_cz, gpiez, kleber, max.howell, os, owb13, sschmidt, steve |
| Priority: | NOR | ||
| Version: | 3.1.2 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
Attachment that causes kdevelop to consume all memory
Another testcase (get.c from Mesa source code) |
||
|
Description
Darke
2005-01-13 13:25:22 UTC
Created attachment 9068 [details]
Attachment that causes kdevelop to consume all memory
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.
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. 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. *** Bug 97492 has been marked as a duplicate of this bug. *** *** Bug 85878 has been marked as a duplicate of this bug. *** 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 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. 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. > > > > 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) Interesting.. can you please specify what pre-3.0 beta release this was? *** Bug 99501 has been marked as a duplicate of this bug. *** *** Bug 99502 has been marked as a duplicate of this bug. *** 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. 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 *** Bug 100588 has been marked as a duplicate of this bug. *** *** Bug 100857 has been marked as a duplicate of this bug. *** *** Bug 109609 has been marked as a duplicate of this bug. *** *** Bug 109466 has been marked as a duplicate of this bug. *** *** Bug 109833 has been marked as a duplicate of this bug. *** Note: bug #109833 contains reproductions steps. 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. Try this patch: http://bruscy.multicon.pl/pages/przemek/patches/kdevelop3.diff Marking as dupe. *** This bug has been marked as a duplicate of 78978 *** 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. 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 |