Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316574

Summary:	[Scanner Discovery] Scanner Config for Makefile project grows indefinitely
Product:	[Tools] CDT	Reporter:	Anton Leherbauer <aleherb+eclipse>
Component:	cdt-build	Assignee:	cdt-build-inbox <cdt-build-inbox>
Status:	NEW ---	QA Contact:	Jonah Graham <jonah>
Severity:	major
Priority:	P3	CC:	jamesblackburn+eclipse
Version:	7.0
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Anton Leherbauer

2010-06-11 03:32:22 EDT

1. Create a Hello World C++ Makefile Project
2. Remember file size of scanner config file
   <workspace>/.metadata/.plugins/org.eclipse.cdt.make.core/hello.sc
3. Close/reopen Eclipse
4. Check file size of scanner config file
   -> it has grown (the increment seems to be its initial size)
5. repeat 2-4

If I change the discovery profile scope from "Per Language" to "Configuration-wide" the scanner config file does not grow on each restart.
Managed build projects are not affected.

Comment 1 Andrew Gvozdev

2010-06-11 09:43:04 EDT

I see this problem goes as far back as CDT 5. At least it's not regression. It appears that id of a tool (related to language) changes which makes the context different. Scanner config then is saved in the file which is intended to keep the data for all contexts.

Comment 2 James Blackburn

2010-06-11 09:52:27 EDT

(In reply to comment #1)
> I see this problem goes as far back as CDT 5. At least it's not regression. It
> appears that id of a tool (related to language) changes which makes the context
> different. Scanner config then is saved in the file which is intended to keep
> the data for all contexts.

I bet this is the cause of the ever-growing .cproject file as well.  Presumably you see anew scanner config element for each of these ids in the .cproject XML too?

Comment 3 Andrew Gvozdev

2010-06-11 10:09:29 EDT

(In reply to comment #2)
> (In reply to comment #1)
> > I see this problem goes as far back as CDT 5. At least it's not regression. It
> > appears that id of a tool (related to language) changes which makes the
> context
> > different. Scanner config then is saved in the file which is intended to keep
> > the data for all contexts.
> I bet this is the cause of the ever-growing .cproject file as well.  Presumably
> you see anew scanner config element for each of these ids in the .cproject XML
> too?
Scanner discovery does not keep discovered data in .cproject. Only scanner discovery profiles are stored there (of course even those which are not relevant to the project). My .cproject is small and I do not see any extra growth.

Comment 4 James Blackburn

2010-06-11 10:38:07 EDT

(In reply to comment #3)
> Scanner discovery does not keep discovered data in .cproject. Only scanner
> discovery profiles are stored there (of course even those which are not
> relevant to the project). My .cproject is small and I do not see any extra
> growth.

I never said it did store discovered data there, and lucky you that it doesn't grow...

I see scanner discovery grow and grow with hundreds of these, not sure what sequence of actions triggers it, but they never go away:

<scannerConfigBuildInfo instanceId="com.broadcom.cdt.build.target.fpexe.debug.1535098180;com.broadcom.cdt.build.target.fpexe.debug.1535098180.;com.broadcom.cdt.build.tool.gnu.c.compiler.base.187864702;com.broadcom.cdt.build.tool.gnu.c.compiler.inputType.1731076159">
	<autodiscovery enabled="true" problemReportingEnabled="true" selectedProfileId="com.broadcom.cdt.build.project.scanner"/>
	<profile id="com.broadcom.eclipse.cdt.make.core.BroadcomGCCStandardMakePerFileProfile">
		<buildOutputProvider>
			<openAction enabled="true" filePath=""/>
			<parser enabled="true"/>
		</buildOutputProvider>
		<scannerInfoProvider id="makefileGenerator">
			<runAction arguments="-f ${project_name}_scd.mk" command="make" useDefault="true"/>
			<parser enabled="true"/>
		</scannerInfoProvider>
	</profile>
	<profile id="com.broadcom.cdt.build.project.scanner">
		<buildOutputProvider>
			<openAction enabled="true" filePath=""/>
			<parser enabled="true"/>
		</buildOutputProvider>
		<scannerInfoProvider id="specsFile">
			<runAction arguments="-E -P -v -dD ${plugin_state_location}/specs.c" command="firepath-elf-gcc" useDefault="true"/>
			<parser enabled="true"/>
		</scannerInfoProvider>
	</profile>
	<profile id="org.eclipse.cdt.make.core.GCCStandardMakePerProjectProfile">
		<buildOutputProvider>
			<openAction enabled="true" filePath=""/>
			<parser enabled="true"/>
		</buildOutputProvider>
		<scannerInfoProvider id="specsFile">
			<runAction arguments="-E -P -v -dD ${plugin_state_location}/${specs_file}" command="gcc" useDefault="true"/>
			<parser enabled="true"/>
		</scannerInfoProvider>
	</profile>
..........

see also bug 199209 comment 4. I've seen .cprojects with 60,000 'profile's' like this. 
Looking at the comment there creating resource descriptions is enough to do it with per-language rather than per-configuration set.