OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000299OMNeT++IDE / C++ developmentpublic2011-05-13 15:432011-05-15 14:25
0000299: CDT tends to lose Source Folder configuration
While working on INET using OMNeT++ 4.2b2, CDT lost the source folder configuration several times.

Normally, the "src" subdir of INET should be the source folder, with multiple folders excluded (those that correspond to disabled project features). However, often CDT would lose this info, and mark the project root as source folder, with no exclusions. One can notice this by diagnostic messages on the Makemake and Project Features project property pages, and sometimes also on the C++ General/Path and Symbols/Source Entries property page; also by a dialog coming up at the beginning of the build that complained that the project config did not correspond to enabled project features. Restoring the correct settings via the project properties dialog would temporarily cure the problem, but it often came back after the first or second build.

We also noticed that sometimes the Makemake page and the CDT Paths and Symbols page had a different idea about source folders.

It also occurred that according to the project properties dialog pages everything was OK, but build triggered the dialog saying that the project config did not correspond to enabled project features.

- It originally occurred after adding an "msvc-debug" config to INET (via the Manage Configurations dialog) on Windows, and using it. Later we reproduced the same problem on Linux, with the "gcc-release" config originally in INET.
- The problem appears to be with the in-memory representation of the config, i.e. not related to the contents of the .cproject file.
- The error usually comes up after building the project multiple times. Cancelled builds didn't count. Whether the build was successful or failed did not seem to matter.
- It appears to be related to switching configurations. If was only one config (you delete all others from the project), it appeared to always work correctly. Also when the first config (of several) was active. When the second or other config was activated, it often broke.

No tags attached.
Issue History
2011-05-13 15:43andrasNew Issue
2011-05-13 15:48andrasNote Added: 0000438
2011-05-13 15:55andrasNote Added: 0000439
2011-05-13 16:01andrasNote Added: 0000440
2011-05-14 14:08andrasNote Added: 0000441
2011-05-15 14:25andrasNote Added: 0000443
2011-05-15 14:25andrasStatusnew => resolved
2011-05-15 14:25andrasFixed in Version => 4.2b3
2011-05-15 14:25andrasResolutionopen => fixed
2011-05-15 14:25andrasAssigned To => andras
2011-05-15 14:27andrasNote Edited: 0000443

2011-05-13 15:48   
After some debugging, we added the following line to the initalization code of ProjectMakemakePropertyPage:


After adding this code (although it is supposed to have no side effect!), our property pages and the CDT Paths and Symbols page at least had the same idea about the source entries.
2011-05-13 15:55   
The problem is apparently in CDT's configration settings management: some data are stored at multiple places, and they sometimes get out of sync...

The following checks were added to the code:

- ProjectMakemakePropertyPage.performOK(): check that the edited settings (from CDTPropertyManager) are correctly written out to CoreModel; i.e. if we read back the source entry settings after setProjectDescription(), we get back the same thing. They were sometimes different; if so, we added code to call setProjectDescription() again, and this appeared to fix it (!!!!).
- Ditto on ProjectFeaturesPropertyPage
2011-05-13 16:01   
Also added a check to the beginning of the build process (at the top of source entries of the active configuration can be accessed both via CoreModel.getDefault().getProjectDescription(prj).getActiveConfiguration().getSourceEntries() and via ManagedBuildManager.getBuildInfo(prj).getDefaultConfiguration().getSourceEntries(); of course both should be the same. However, the two sometimes differed, with ManagedBuildManager's version being the correct one. So we added the kludge that we whenever the two differ, we take the ones from ManagedBuildManager and set it onto CoreModel. This rudimentary "fix" greatly reduced the occurrence of the error.
2011-05-14 14:08   
The above kludges do not work realiably, rolling back.

More insight:

The wrong source entries data (prj root folder w/ no exclusions) is a default, which comes from CDataUtil.adjustEntries() [invoked from CConfigurationDescription's initSourceEntries(), in turn invoked from getSourceEntries()]:

    public static ICSourceEntry[] adjustEntries(ICSourceEntry entries[], boolean makeAbsolute, IProject project){
        if(entries == null || entries.length == 0)
            return getDefaultSourceEntries(makeAbsolute, project); <=== HERE

By placing a breakpoint on the marked line, one can verify that bogus source entries only occur after that line has been executed. The wrong entries are then cached in CConfigurationDescription and continue to cause trouble.

On starting the IDE, the above line is executed while the following frames are on the call stack:

    CDataUtil.adjustEntries(ICSourceEntry[], boolean, IProject) line: 811
    CConfigurationDescriptionCache.initSourceEntries() line: 387
    CConfigurationDescriptionCache.getSourceEntries() line: 380
    CConfigurationDescription.getSourceEntries() line: 495
    MakefileTools.collectDirs(ICProjectDescription, List<IContainer>, String) line: 207
    MSVCDiscoveredPathInfo.<init>(IProject) line: 56
    CProjectDescription.loadDatas() line: 196

Thus, MSVCDiscoveredPathInfo seems to invoke getSourceEntries() WHILE THE PROJECT DESCRIPTION IS BEING LOADED. This seems to be the root cause of the problem.

When commenting out the relevant lines from MSVCDiscoveredPathInfo ctor and from OmnetppProjectMacroSupplier.SourcePathMacro.getStringValue(), the error completely goes away.


Apparently one is not supposed to access the configuration description (or at least the source entries) from toolchain plug-in classes like macro providers, scanner info collectors, discovered path info providers, etc.
2011-05-15 14:25   
(edited on: 2011-05-15 14:27)
Resolved by eliminating all ICConfigurationDescription.getSourceEntries() calls from macro supplier and scanner info collector classes. Project include folders are now collected separately in the new IncludeFoldersCache class (which does it in resource change listeners), and scanner info collectors just take it from there.