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

Bug 333001

Summary: Description Scanner Info doesn't release ICProjectDescription
Product: [Tools] CDT Reporter: Marko Tomljenovic <marko.tomljenovic>
Component: cdt-coreAssignee: Andrew Gvozdev <angvoz.dev>
Status: RESOLVED FIXED QA Contact: Andrew Gvozdev <angvoz.dev>
Severity: major    
Priority: P3 CC: jamesblackburn+eclipse, yevshif
Version: 7.0.1   
Target Milestone: 8.1.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Screenshot of heap dump after aout of memory
none
Leak Report from Memory Analyzer none

Description Marko Tomljenovic CLA 2010-12-21 05:45:31 EST 
Build Identifier: 7.0.1

We have a test suite that creates/deletes a CDT project a lot. Each of the projects has several hundreds symbols (stored in the project properties of the project through ExternalSettingsProvider extension point).

When running the tests we finally get an "out of heap memory" error.

It looks like: CProjectDescription of deleted projects is not garbage collected because the DescriptionScannerInfoProvider is still a listener in the CProjectDescriptionManager. Since each CProjectDescription holds the reference to all the symbol (several hundreds), the system runs out of memory.

Reproducible: Always
Comment 1 Marko Tomljenovic CLA 2010-12-21 05:46:52 EST 
Created attachment 185621 [details]
Screenshot of heap dump after aout of memory
Comment 2 Andrew Gvozdev CLA 2011-03-01 17:16:26 EST 
Can you provide a simplified test case which leaks the listener?
Comment 3 Marko Tomljenovic CLA 2011-04-12 08:18:02 EDT 
Created attachment 193038 [details]
Leak Report from Memory Analyzer

I did another test where I imported 15 projects in sequence. In the leak.png pic it can be seen that there are 15 XMLStorage objects that are not cleared when a project is removed.
In addition there are also 5 objects of type CCOnfigurationDescriptionCache that are also not cleared.

I will do my best to provide a test case for this problem but it is very hard to do so.
Comment 4 Marko Tomljenovic CLA 2011-04-12 08:39:20 EDT 
The problem is that everybody can register itself as a ICProjectDescriptionListener using CProjectDescriptionManager.addCProjectDescriptionListener(). The only way to prevent a memory leak here without chaning the API is that all listener must listen to project remove/close/move events and deregister itself properly.

A nicer way would be if the description managers api could be changed in a way so that listeners are registered for project so that the manager can remove them automatically when a project is removed,...
Comment 5 Andrew Gvozdev CLA 2011-07-14 18:35:58 EDT 
I am experiencing that too. I can see 2 listeners that are being leaked, ScannerInfoProviderProxy and DescriptionScannerInfoProvider which is added during build.
Comment 6 Andrew Gvozdev CLA 2011-07-15 10:52:55 EDT 
Committed changes to master, could you verify that it resolves the memory leak?
Comment 7 CDT Genie CLA 2011-07-15 15:30:08 EDT 
*** cdt git genie on behalf of 333001 ***

    bug 333001: Description Scanner Info doesn't release
    ICProjectDescription

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=63f72f39e12c968bbfe3ec7c158de43936ec48de
Comment 8 Andrew Gvozdev CLA 2011-07-16 14:11:52 EDT 
There is one more leak in this scenario, CModelManager.binaryMap. Fixed on master as well.
Comment 9 CDT Genie CLA 2011-07-16 14:20:10 EDT 
*** cdt git genie on behalf of 333001 ***

    bug 333001: Description Scanner Info doesn't release
    ICProjectDescription

[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=f0d815e69e59901c1c9fd1e33a7870286b244675
Comment 10 Marko Tomljenovic CLA 2012-01-25 15:52:49 EST 
This bug seems to be appearing again in 8.0.1. Can somebody pls check it out?
Comment 11 Andrew Gvozdev CLA 2012-01-25 16:20:26 EST 
There was no claim that it was fixed in 8.0.1. The fix was done on master only (9.0).
Comment 12 Marko Tomljenovic CLA 2012-01-25 16:25:12 EST 
(In reply to comment #11)
> There was no claim that it was fixed in 8.0.1. The fix was done on master only
> (9.0).

Oh yeah, you are right! I am sorry for the inconvenience.
Comment 13 Andrew Gvozdev CLA 2012-01-25 16:33:08 EST 
Closing bug then.