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

Bug 331570

Summary: StackOverlow when setting build artifact name to anything with ${PWD}
Product: [Tools] CDT Reporter: Alex Freidin <freidin.alex>
Component: cdt-build-managedAssignee: Project Inbox <cdt-build-managed-inbox>
Status: NEW --- QA Contact: Jonah Graham <jonah>
Severity: normal    
Priority: P3 CC: cdtdoug, yevshif
Version: 8.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch with the above suggestion none

Description Alex Freidin CLA 2010-12-01 12:17:18 EST
Build Identifier: M20100909-0800

Stack overflow due to infinite recursion when setting artifact name to anything with ${PWD} variable.

Steps to reproduce:

1.Create Hello World project
2.Open Project > Properties > C/C++ Build > Settings
3.Select "Build Artifact" tab and at "Artifact Name" field type ${PWD}/MyApp or simply ${PWD}.
4.Press OK, observe the "Internal Error - java.lang.StackOverflowError" window pops up.

The reason why this variable (and ${CWD}) is handled differently than others lies in MBSEnvironamentVariableSupplier.getConfigurationVariable(String name, IConfiguration configuration) that has a special case for it: if("CWD".equals(name) || "PWD".equals(name)). This IF statement causes the infinite recursion to start. It calls to ManagedBuildManager.getBuildLocation(), which in turn calls to GnuMakefileGenerator.initialize(), which tries again to resolve all macros/variables and it becomes a loop.

Reproducible: Always
Comment 1 Alex Freidin CLA 2010-12-07 11:21:44 EST
The rather simple Builder.getDefaultBuildPath() seems like an overkill. Specifically, it fully initializes the makefile generator (which causes the recursion) although the caller doesn't need the generator except for the path. There is no existing API method to replace initialization. So the API either needs be extended or the recursion stopped inside IManagedBuilderMakefileGenerator2.initialize(). But that means that custom generators will still fall into the same trap. This way or another, custom generators will require a change.
Any opinions?
Comment 2 Alex Freidin CLA 2010-12-19 09:44:20 EST
Both ManagedBuildManager.getBuildLocation() and Builder.getBuildPath() are called very frequently and fully initialize the makefile generator. This is a bad idea and leads to recursion. There should be a utility method for this purpose.
The IManagedBuilderMakefileGenerator2 API should be extended with a new method that receives configuration and returns the build working directory. E.g. IPath getBuildWorkingDirForConfiguration(IConfiguration cfg). This resolves the recursion and improves performance.
Comment 3 Alex Freidin CLA 2010-12-19 09:54:57 EST
Created attachment 185496 [details]
Patch with the above suggestion