Community
Participate
Working Groups
On the latest Kepler Master branch. Client: Red Hat Enterprise Linux Server release 6.2 (Santiago) Server: Red Hat Enterprise Linux Server release 6.4 (Santiago) 1. I created a new synchronized project to a hello_world program. 2. When the creation was finished I noticed that the C/C++ Indexer was running in the message area at the bottom right corner of the screen. 3. So I opened the progress view and was surprised to see the C/C++ Indexer running constantly and the "Discover compiler built-in language setting (waiting)" occurring over and over and over. See attached image. For the next 5+ minutes as I entered this bug it has not stopped, but continues to span new ones.
Created attachment 231809 [details] Image showing Porgress view with C/C++ Indexer running over and over
Note: If I try stopping [red square on right] the various tasks then new ones appear and take their place. I cannot ever get it to purge all of these tasks and quiesce. I consider this an important error to fix.
Second Note: If I then try to do a clean or a build, the Clean or Build task takes a long time to complete because it is Build Project (Blocked: The user operation is waiting for "Discover compiler built-in language settings" to complete)
Maybe related the log has: !ENTRY org.eclipse.cdt.managedbuilder.core 4 0 2013-05-31 08:34:39.678 !MESSAGE Problem running CDT Scanner Discovery provider org.eclipse.ptp.rdt.sync.core.SyncGCCBuiltinSpecsDetector !SUBENTRY 1 org.eclipse.cdt.managedbuilder.core 4 4 2013-05-31 08:34:39.679 !MESSAGE Error running Builtin Specs Detector !STACK 0 java.lang.NullPointerException at org.eclipse.ptp.internal.remote.remotetools.core.RemoteToolsFileStore.getExecutionManager(RemoteToolsFileStore.java:455) at org.eclipse.ptp.internal.remote.remotetools.core.RemoteToolsFileStore.getRemoteItem(RemoteToolsFileStore.java:499) at org.eclipse.ptp.internal.remote.remotetools.core.RemoteToolsFileStore.fetchInfo(RemoteToolsFileStore.java:184) at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:280) at org.eclipse.ptp.internal.rdt.sync.cdt.core.SyncGCCBuiltinSpecsDetector.getSpecFile(SyncGCCBuiltinSpecsDetector.java:277) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.resolveCommand(AbstractBuiltinSpecsDetector.java:306) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.startupForLanguage(AbstractBuiltinSpecsDetector.java:543) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.runForEachLanguage(AbstractBuiltinSpecsDetector.java:495) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector$1.runInWorkspace(AbstractBuiltinSpecsDetector.java:430) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
The above may occur because I was banging cancel/stop numerous times on various tasks and they were shutting-down/stopping at weird places. If I stop Eclipse and restart it NO back traces are present until I start canceling/stopping the tasks. When the back traces occur they can be other failures than NPE.
Created attachment 231811 [details] Image showing Progress view when submitting a job while C/C++ Indexer running over and over
Set Importance to P2 major
Going into Window > Preferences > C/C++ > Indexer I get "Could not Accept Changes: The currently displayed page contains invalid values". If I press OK and then reattempt to select Indexer now I get the Indexer Preference page with nothing set (no checkboxes checked, no indexer choice selected). If I press OK the Indexer task stops running. Now only the "Discover compiler build-in language settings" task is running over and over.
Created attachment 231814 [details] Image of Progress view after Indexer is stopped
How many other projects do you have in your workspace? Last night I fixed bug 409479, so that the sync scanner discovery now runs. So it could be that it is running discovery on all of your projects because it detects that none of them have yet been run. The C/C++ indexing also takes a long time, even on small projects, which would explain the backup of tasks.
One project, the hello world one with hello_world.c of 5 lines.
Just deleted the workspace (runtime-Eclipse) and restarted Eclipse. Created the hello_world synchronized project again afresh and the C/C++ Indexer & Discover scanner started again running over and over.
What is weird is that the Indexer is grossly misstating things like "Indexing: 334/341 sources, 22 headers: parsing hello_world.c (/test_hello_world_Linux_x86_64)" and the hello_world.c program consists of: /* * hello_world.c * * Created on: May 8, 2013 * Author: bwatt */ #include <stdio.h> #include <unistd.h> int main(int argc, char **argv) { char name[256] = ""; gethostname(name, 256); printf("Hello World from %s!\n", name); sleep(600); return 0; }
Definitely seeing bug 409479 comment 2 "However, removing this causes the scanner discovery/indexer to get into an infinite loop."
For me the sync discovery doesn't run at all when the project is created. I have to invoke it manually as described in bug 409479. Then it runs once followed by the indexing. How exactly are you creating the project? What project type and toolchains do you select and what files, if any, are on the remote? Also, what version of CDT are you using?
(In reply to comment #15) > For me the sync discovery doesn't run at all when the project is created. I > have to invoke it manually as described in bug 409479. Then it runs once > followed by the indexing. How exactly are you creating the project? What > project type and toolchains do you select and what files, if any, are on the > remote? Also, what version of CDT are you using? How exactly are you creating the project? Right click on Project Explorer area > "New" > "Synchronized C/C++ Project". Enter project name: "test_hello_world_Linux_x86_64". Under "Remote directory" "Connection name": select "k7.pok.ibm.com" from list or create it "New" if connection doesn't exist. Under "Remote directory" "Remote directory": select "Browse" and find "/home/bwatt/test_client/remote_projects_linux/test_hello_world_Linux_x86_64". The remote system contains all the files: hello_world.c and Makefile. If already built it also contains hello_world.o and hello_world executable. Under "Project Type" expand "Makefile project" and select "Empty Project". Under "Remote Toolchain (select 1 or more)" select "Linux GCC". Do not select a "Local Toolchain" Press "Finish" Also, what version of CDT are you using? Eclipse C/C++ Development Tools SDK Version: 8.2.0.201305061014
I haven't tried this out, but I noticed on the last page of the project creation there are some sync setting dropdown menus with nothing selected by default. Could this be causing an issue?
Again deleted the workspace (runtime-Eclipse) and restarted Eclipse. Created the hello_world synchronized project again afresh, but this time WITHOUT specifying any "Remote Toolchain (select 1 or more)". And the Indexer/Discovery Scanner are NOT running over and over. So I can make progress this is a workaround I'll use for the time being until this is fixed.
(In reply to comment #17) > I haven't tried this out, but I noticed on the last page of the project > creation there are some sync setting dropdown menus with nothing selected by > default. Could this be causing an issue? I don't think so, because those settings only affect which build configuration is selected, and in this case there is only one.
I'm seeing a similar issue. I would expect there to be a significant number of header files processed, since system headers include other headers, etc. However, I left the indexing running for a couple of hours, and it is now up to over 9,500 source files and 2,500 headers while indexing shallow/main.c. It does appear that there is some kind of looping problems.
I added a lock to prevent multiple threads from running scanner discovery at the same time. Please test and see if this helps.
So I pulled the latest master code, and then I followed the aforementioned scenario after deleting the project from my workspace. The behavior is no different. That is, the C/C++ Indexer begins to run. Over time the Indexing of the sources starts at 0/3 and progress over several minutes to about 360/367 (numbers not exact). Then it resets back to zero and starts all over again. Another time it went even longer and got over 1000/1008 before I finally gave up and stopped Eclipse.
To make sure I have pulled the latest master code to test please tell me the plugin that was affect by your latest change so I can verify that the change in the the history.
Yes, the behavior is still the same for me.
For the org.eclipse.ptp.rdt.sync.cdt.ui the last change I see is: commit 62692b3596547594489e95eef1ba4a10691ce789 Author: John Eblen <jeblen@acm.org> 2013-05-30 18:47:55 Committer: John Eblen <jeblen@acm.org> 2013-05-30 21:07:40 Parent: c40f9df113d0c2b8a34e548e290728425c52938a (Bug 409395 - Without toolchain selection, New Sync project gives NPE) Branches: master, origin/master Bug 409479 - Sync GCC Builtin Compiler Settings not working Also includes improvements to sync scanner discovery: 1) Do not sync before or after discovering built-in compiler settings 2) Do not share providers between projects
OK, I see it, for org.eclipse.rdt.sync.cdt.core, I see commit 3980a80c249e726acd14b5fb22105bdba330b373 Author: John Eblen <jeblen@acm.org> 2013-05-31 13:59:18 Committer: John Eblen <jeblen@acm.org> 2013-05-31 14:07:22 Parent: 62692b3596547594489e95eef1ba4a10691ce789 (Bug 409479 - Sync GCC Builtin Compiler Settings not working) Branches: master, origin/master Add lock to prevent multiple sync scanner discovery jobs running at the same time. See bugs 409479, 409587, and 409609.
Yes, that is the commit. I think there are two issues: the runaway indexing and the constant adding of new discovery jobs. This commit targets the latter problem. Do you still see lots of discovery jobs in the queue? If so, are there fewer now than before? Unfortunately, I'm not able to reproduce the problem, so I can't see the results for myself.
(In reply to comment #27) > Yes, that is the commit. I think there are two issues: the runaway indexing > and the constant adding of new discovery jobs. This commit targets the > latter problem. Do you still see lots of discovery jobs in the queue? If so, > are there fewer now than before? Unfortunately, I'm not able to reproduce > the problem, so I can't see the results for myself. John, I have not been focusing on the discovery jobs, so I cannot reply to your question since I don't know if there are more or less now. Sorry.
(In reply to comment #28) > John, I have not been focusing on the discovery jobs, so I cannot reply to > your question since I don't know if there are more or less now. Sorry. In earlier comments you said that the long list of discovery jobs, which queue behind the indexing job, kept regenerating and that you were unable to purge all of the jobs (comment #2). Does that still occur? My hope is that now there is only one discovery job or at least a finite number, say 7 or 8, and that they do not continually regenerate.
(In reply to comment #29) > (In reply to comment #28) > > John, I have not been focusing on the discovery jobs, so I cannot reply to > > your question since I don't know if there are more or less now. Sorry. > In earlier comments you said that the long list of discovery jobs, which > queue behind the indexing job, kept regenerating and that you were unable to > purge all of the jobs (comment #2). Does that still occur? My hope is that > now there is only one discovery job or at least a finite number, say 7 or 8, > and that they do not continually regenerate. So here is what I see now. 1. The indexer task is running 48/51 sources...51/54 sources...54/47 sources... 2. There are N discovery task beneath the indexer. Where N is upwards to 10-15 of them (see attachment 4 [details]) 3. Over time the discovery tasks complete. 4. When all discovery tasks complete the indexer is reset to 0/0 sources and N more discovery tasks are created where might be more this time, and the whole things starts over again. I'd be more than willing to call you and also set up a web conference so you can watch it.
Created attachment 231878 [details] Image of Progress View with recently regenerated discover tasks
I see similar behavior to Brian. I created a new workspace, then a new synchronized C/C++ project using a remote project that already existed. 1. It looks like the indexer may have started before the synchronization was completed. Not sure if this has any effect. 2. I see the indexed job, then about 10 Discover jobs. Each Discover job completes in turn until they are all done, then another 10 or so appear. 3. The indexer says Indexing: 0/10 sources, then by the time the 10 jobs are done it says something like 4/10 sources. When the second lot of 10 jobs are done, it is now indexing 15/29 sources. 4. The number of sources just keeps increasing. For interest, I let it run all day over the weekend and it got to about 60,000 sources indexed before running out of heap space.
I can refer to bug 407781 and bug 408541. If somebody can provide reduced reproducible example, I would take a look at looping from CDT side. Also, bug 406069 might be of interest.
BTW, I am running Eclipse C/C++ Development Tools Version: 8.2.0.201305291013
John, I wonder if we should revert this change? Sync projects kill my whole workspace currently.
Workaround: Created the synchronized project, but WITHOUT specifying any "Remote Toolchain (select 1 or more)". As a result the Indexer/Discovery Scanner DO NOT run over and over.
(In reply to comment #36) > Workaround: Created the synchronized project, but WITHOUT specifying any > "Remote Toolchain (select 1 or more)". As a result the Indexer/Discovery > Scanner DO NOT run over and over. I presume this is because the remote build configuration is not created, so no scanner discover is run. I guess the other workaround is to manually disable the Sync scanner discovery provider in the Preprocessor Include Paths property page.
(In reply to comment #37) > (In reply to comment #36) > > Workaround: Created the synchronized project, but WITHOUT specifying any > > "Remote Toolchain (select 1 or more)". As a result the Indexer/Discovery > > Scanner DO NOT run over and over. > > I presume this is because the remote build configuration is not created, so > no scanner discover is run. I guess the other workaround is to manually > disable the Sync scanner discovery provider in the Preprocessor Include > Paths property page. No, a remote toolchain is still created. The sync scanner discovery is only added when the toolchain contains the GCC scanner discovery (the latter is removed). So any non-GCC toolchain will not have the sync scanner discovery.
(In reply to comment #35) > John, I wonder if we should revert this change? Sync projects kill my whole > workspace currently. Yes, if we are unable to fix this problem. Fortunately, it should be easy to alter the code to simply not add the sync scanner discovery, no need to revert commits, and it would still be available for the user to add after the project is created.
Will you do this for RC3? It needs to be done today if possible.
Okay, sync scanner discovery providers are no longer enabled by default.
Just pulled down the latest code, created a new synchronized project to a hello_world program, and specified Under "Project Type" expand "Makefile project" and select "Empty Project" along with under "Remote Toolchain (select 1 or more)" select "Linux GCC". I am no longer seeing the C/C++ Indexer running constantly and the "Discover compiler built-in language setting (waiting)" occurring over and over and over. All fixed. Closing.
Brian, I'd like to keep this open. John has just changed the sync config so that the sync scanner discovery is not enabled by default. This should be enabled by default, so the root cause of the problem still needs to be determined.
Greg, sure, that's your choice. I just wanted to properly respond the immediate comment and issue versus your desire to later address the greater problem. So that's fine by me.
I use to get this problem occasionally using Eclipse Oxygen C/C++ under Windows 10. Now I am running Eclipse 2018-09 (still under Windows 10) and it is MUCH worse. So bad that I will have to downgrade to a previous version, because I often have to wait 10 minutes or more before I can start a build. Many of the CDT Scanner discovery tasks appear to be duplicates because they use exactly the same command and parameters. See attachment. By the time it has completed some of the scanner discovery tasks, it has usually created several more. Could it be that when the CDT checks to see whether it needs to run scanner discovery, it doesn't check whether it has already launched a task to run exactly the same scanner discovery?
Created attachment 276602 [details] Screen shot of many scanner discovery tasks
(In reply to David Crocker from comment #45) I may be wrong about this issue being worse in Eclipse 2018-09 than in Oxygen, because I suspect it was triggered by the upgrade to 2018-09, which may have caused Eclipse to initiate discovery simultaneously for multiple configurations of multiple projects (I have 11 projects in the workspace and up to 9 configurations of each). Also I think part of the problem may be a Windows bug or an interaction between Eclipse and Windows whereby creating and launching processes becomes very slow. I left Eclipse running for up to half an hour at a time, and when Eclipse became total unresponsive I attempted to close it, terminated it if it wouldn't close, and rebooted Windows (I had to do this 3 times). Now it's running about as well as Oxygen did, and rarely running compiler discovery.
