Bugzilla – Full Text Bug Listing
| Summary: | The 'Binaries' node does not always disappear when project is cleaned | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Baltasar Belyavsky <bbelyavsky> | ||||||
| Component: | cdt-core | Assignee: | Anton Leherbauer <aleherb+eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aleherb+eclipse, evil_bandit_betamax, jamesblackburn+eclipse, malaperle, marcin.swiezawski, recoskie, yevshif | ||||||
| Version: | 8.0 | ||||||||
| Target Milestone: | 8.7.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| See Also: |
https://git.eclipse.org/r/46093 https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=ce8be9513d95970aee2032bf91d5f4d479c24a5c |
||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Baltasar Belyavsky
Interesting, the clean it can't find rm.exe in PATH then it works correctly but if it uses rm.exe then it is as you say, the binaries node doesn't disappear. Could it be that the file is considered to be deleted externally to the workspace when it correctly uses rm? (In reply to comment #1) > Interesting, the clean it can't find rm.exe in PATH then it works correctly but > if it uses rm.exe then it is as you say, the binaries node doesn't disappear. > Could it be that the file is considered to be deleted externally to the > workspace when it correctly uses rm? Woops, this should read: Interesting, if the clean can't find rm.exe in PATH then it works correctly but if it uses rm.exe then it is as you say, the binaries node doesn't disappear. Could it be that the file is considered to be deleted externally to the workspace when it correctly uses rm? The problem seems to be that the CProject gets closed by the ScannerConfigBuilder via a SetCProjectDescriptionOperation. Closing the CProject releases all its ICElements, including IBinaryContainer and its contained IBinaries. When a first build is done, this is not a problem because right after the CProject is closed, the ResourceDeltas for the newly added binaries get sent to the CModelManager and the IBinaryContainer/IBinaries are then created. But when the project is built a second time, the only thing that happens is the CProject.close (from ScannerConfigBuilder/SetCProjectDescriptionOperation) so the model is left without a IBinaryContainer/IBinary. Then when the project is cleaned, a ResourceDelta for the deleted binary is sent to the CModelManager but because there is no IBinaryContainer and no IBinary, this doesn't generate a proper ICElementDelta which means the view doesn't see the change. If I remove the cproject.close call in SetCProjectDescriptionOperation then it works correctly and I don't know why it is there in the first place (there's also a comment //why?). On the other hand, I feel like this is a flaw in the CModel: 1. Add binary (Adds it to CModel) 2. CProject.close (removes elements) 3. CProject.open (re-creates elements but not binaries) 4. Delete binary resource Result: ICElementDelta is not generated I'm not sure what would be the solution here. I don't think running the BinaryRunner part of the CProject.open is reasonable since it can be a long running job. And removing the cproject.close call inside SetCProjectDescriptionOperation seems kind of scary. Created attachment 207896 [details]
CModel test
Created attachment 207898 [details]
Potential scary fix
(In reply to comment #5) > Created attachment 207898 [details] > Potential scary fix Looks like the best experts we can find in the field were also puzzled with the statement you are removing. That was James' comment. James, have you gotten any more insight on that since? I'd say if nobody knows why it is there and it causes problems, let's fix it right to the best of our knowledge. There is still plenty of time to test before Juno release. (In reply to comment #6) > (In reply to comment #5) > > Created attachment 207898 [details] > > Potential scary fix > Looks like the best experts we can find in the field were also puzzled with the > statement you are removing. That was James' comment. James, have you gotten any > more insight on that since? Are you sure it was James? I see Chris in the Git log. (In reply to comment #7) > Are you sure it was James? I see Chris in the Git log. James was not CDT committer at the time but he authored the changes. Just take a look at the list of attachments in bug 252966, it is impressive. (In reply to comment #6) > (In reply to comment #5) > > Created attachment 207898 [details] > > Potential scary fix > Looks like the best experts we can find in the field were also puzzled with the > statement you are removing. That was James' comment. James, have you gotten any > more insight on that since? Nope, not really. It perplexed me at the time. I guess the only thing to worry about is that no close()ing may introduce a leak somewhere? Certainly removing confusion (and adding tests is to be welcomed :) ). Comment on attachment 207898 [details]
Potential scary fix
I see why it is there now. Some information in the CModel cache depends on the CProjectDescription. For example, CContainerInfo caches the non-C resources (like excluded files). By closing the CProject, that cache is deleted and rebuilt from CProjectDescription when needed. As a test, I removed the cProject.close line and excluded some files then I could see the cache not being rebuilt and the icons for exclusion became out of sync. So... removing the cProject.close line alone is not the solution.
I'm currently experiencing this problem. I'm actually hunting for a reproducible test case for "Bug 387075 - Binary folder intermittently does not appear after a CDT project Build" https://bugs.eclipse.org/bugs/show_bug.cgi?id=387075. I have a workspace consisting of 13 test projects, which I am repeatedly building and cleaning. So far I can't reproduce 387075, but when I clean the workspace, I repeated see between 1 and 3 projects that maintain their Binaries folder when no binaries exist. After reading comment 3 about "ScannerConfigBuilder via a SetCProjectDescriptionOperation" I was reminded of a patch I incorporated into my product to fix "Bug 436060 - Race condition in CProjectDescriptionManager.updateProjectDescriptions()"; I'm wondering if there is potentially a race in SetCProjectDescriptionOperation which could be causing the Binaries folder showing/not showing problem? The randomness of this issue seems to suggest it could be a race, but I don't possess the experience in this area necessary to detect such a race condition, but just offer this as an idea. The whole issue of the Binaries folder appearing/not disappearing when it should is for experienced Eclipse users an inconvenience; a refresh of the project normally fixes the issue (actually sometimes I've found that is not enough. Occasionally it is necessary to close and reopen the project for the Binaries node to fully represent the filesystem status). However, for new Eclipse users it can be a significant blocker. New Gerrit change created: https://git.eclipse.org/r/46093 I have a fix for this issue. Due to the CProject.close() no delta for the binary container is created when a binary is removed. This needs to be taken care of in the DeltaProcessor. A similar issue is that manually deleting only the executable does not remove the Binary node, although it is empty. This is a UI refresh issue which is also covered by the change. I took the freedom and included the CModel test by Marc-Andre, which succeeds now. Gerrit change https://git.eclipse.org/r/46093 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=ce8be9513d95970aee2032bf91d5f4d479c24a5c Fixed in master. Thanks for the fix. |