Community
Participate
Working Groups
Using Eclipse-3.0 (GTK version) and CDT-2.0 on Fedora Core 2 Linux using j2sdk1.4.2, sometimes (nearly always) as soon as I make the slightest change to a file the Outline window starts flashing like mad and CPU load maxes out. It seems that the outline function is stuck in an infinite loop trying to update for the change I have made. Sometimes, but not always, the symptoms disappear when I save the file. Removing the outline from the display does not cure the problem once it has started. Killing the editor (i.e. closing the file) and reopening it results in an outline display without the looping behaviour (until the next change is made). The source code being edited at the time was the Linux-2.6.7 kernel. A file for which the behaviour was observed is kernel/sched.c but other files were similarly effected.
Created attachment 12973 [details] This is a file for which the reported behaviour was observed
Currently I am looking into this.
Fixed in Head and branch.
*** Bug 70089 has been marked as a duplicate of this bug. ***
This bug is still present in CDT-2.0.1 but not as bad (or as obvious). The "outline" no longer flashes continuously after an update to a file but the system CPU usage rate jumps to approx. 100% and some editing functions (namely copy and cut) cease to work. After about 40 seconds or so the CPU usage rate returns to normal and the copy and cut start working again.
I turned off both build automatically and indexer. Now CPU hovers around 40% when editing any size file. The file included with this defect is ~5000 lines and takes a minute on my machine to get CPU down again. With a 256 line file, it takes about 4 seconds. While the CPU is up at 40% (or 100% if indexer is on), I can't do cut or copy either, nor switch pages in the project properties or preferences.
Alain, can you look at this? This seems to be the problem people are complaining about on the newsgroup. You can use the attached file to reproduce the cpu spike and non-responive UI. The problem is not with the index/parse. If I suspend during this cpu spike, invariably the main thread is somewhere in the middle of refreshing the outline view. If we can figure out whats wrong, this would be something we should include in the 2.0.2 respin
The reconciler is calling fOutlinePage.contentUpdated() some 350 odd times after I make a simple 1 line change, each one of which results in a refresh job on the main thread.
> The reconciler is calling fOutlinePage.contentUpdated() some 350 odd times > after I make a simple 1 line change, each one of which results in a refresh > job on the main thread. Right. This was fix in the head. The way it was done before was not ... very ... practical. Whether I can move the "fix" from the head to the branch without too much destabilization is another thing. Give a try on the head tell me if you see an improvement. The attachement is corrupted ... part of the file is missing at the end.
The cpu problem does seem to be fixed in the head. However, the head is unable to create an editor for this file. 2.0.1 opens it fine. In fact, there seems to be a couple of files in my workspace that 2.0.1 opens that the head won't. If I create a new file in my project, then paste the contents of sched.c into it, things are ok and the cpu is fine after making changes. If I then save and close that editor, the cdt is unable to reopen that file.
> The cpu problem does seem to be fixed in the head. Allright, I'll try to isolate the fix and move it to 2.0.1 > However, the head is unable > to create an editor for this file. 2.0.1 opens it fine. In fact, there seems > to be a couple of files in my workspace that 2.0.1 opens that the head won't. I do not have this problem here. Try: - Turning off #follow includes, to reduce the parser demands. The only thing I can thing of is the parser going on loop
The inability to open the editor is because of an exception coming out of the code folding, it doesn't happen if you turn code folding off. ( in CEditor.createPartControl: if(isFoldingEnabled()) projectionViewer.doOperation( ProjectionView.TOGGLE ); throws an org.eclipse.jface.text.Assert$AssertionFailedException ) I'll raise a seperate bug for this once I can find a smaller example that does the same.
> The inability to open the editor is because of an exception coming out of the > code folding, it doesn't happen if you turn code folding off. Damned!! Forget the coffe. >> The only thing I can thing of is the parser going on loop It is a good thing, I did not put some $$ to back that claim. > I'll raise a seperate bug for this once I can find a smaller example > that doesthe same. Raise the PR nevertheless, and attach the log. I've already put workarounds in the head for bugs in the ProjectViewer. The UI folks knows about it. Meanwhile I'll put a fix in the branch for the outliner. Could you verify please ..
Aniefier, Can you verify, that I did not do any other damage 8-) In the branch 2_0
looks good so far
> looks good so far Can I take this as a Verified ?
I noticed before that when turning on follow #includes, and then editing this file, the cpu wasn't so high, but it took a lot longer to be able to edit again. Also the outline view wasn't showing all the methods in sched.c (just shows macros and includes) after updating with follow #includes on. Now the bug is fixed where you can edit without waiting for the update, and the cpu stays low, but the outline view still doesn't show the methods if you have follow #includes on. Is this something related to the bug or a separate bug?
That would be a bug. However, you need a full workspace (w/header files, inclusions, etc.) in order for me to debug it.
Created bug 73692.
