-
Notifications
You must be signed in to change notification settings - Fork 107
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
Tactical mem leak fix for aggregation #673
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursory comments - will look in more detail next week.
|
||
// Manual for now - verify that all APIs targeting 19041 generate a warning | ||
// Consider invoking roslyn and scraping/analyzing output as an automated test | ||
private void Test() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a feedback for this PR, but as an FYI, we can probably automate this test this by creating a C# compilation context and triggering a compilation on it and then checking for diagnostics. An example of this is the diagnostics test which Joshua wrote which do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to open an issue with specific suggestion
My main concern with this technique is that when _inner is disposed before its owner is finalized, the finalizer has no chance to detach and the refcount is too low by 1. Since finalizers can run on any thread, in any order, I'm not confident that keeping the inner refcount artificially low is a reliable fix here. In fact, I think any approach that tries to do so is doomed. There's just no safe way to defer an AddRef while still holding onto a COM pointer - it's a time bomb.