Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitigate memory leak and disable affected tests #761

Merged
merged 1 commit into from
Feb 21, 2015

Conversation

jasonmalinowski
Copy link
Member

All the disabled tests are associated with issue #759 which tracks
re-enabling these.

All the disabled tests are associated with issue dotnet#759 which tracks
re-enabling these.
@mavasani
Copy link
Contributor

Thanks, I'll work on fixing these asap. 👍

jasonmalinowski added a commit that referenced this pull request Feb 21, 2015
Mitigate memory leak and disable affected tests
@jasonmalinowski jasonmalinowski merged commit 96f82a0 into dotnet:master Feb 21, 2015
@jasonmalinowski jasonmalinowski deleted the fix-memory-leaks branch February 21, 2015 01:41
mavasani added a commit that referenced this pull request Feb 22, 2015
My prior change #673 made to address issues with analyzer exception diagnostics introduced a few leaks in product and test code. The primary reason was that I attempted to use static events to track state as the existing AnalyzerDriverHelper type which did the core analyzer execution was a static type with all static methods. Additionally, I added a static event to the new host diagnostic update source added for reporting analyzer specific diagnostics. These were holding onto projects/workspaces in test runs causing leaks.

I have reverted the approach of static events and instead refactored the code in AnalyzerDriver project to simplify the whole design:
 1. Renamed AnalyzerDriverHelper to AnalyzerExecutor and made it a non-static type, which has instance fields for all the configuration parameters for analyzer callbacks.
 2. Move all the core analyzer callbacks (actions/Initialize method/supported diagnostics) into AnalyzerExecutor. Command line compiler just creates a single instance of the executor, while IDE driver creates instances per analyzer. 
 3. Both these changes simplified the API a lot, and I just had to add an additional field "Action addExceptionDiagnostic" to AnalyzerExecutor to configure how to handle exception diagnostics.
 4. MEF import AbstractHostDiagnosticUpdateSource in DiagnosticAnalyzerService and thread it down to IDE analyzer driver.
 5. Changes 3 and 4 above meant that in the IDE driver, delegate "addExceptionDiagnostic" just asks the HostDiagnosticUpdateSource to report the exception diagnostic produced by the AnalyzerExecutor.

This change also re-enables the tests skipped by #761 and fixes #759.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants