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

Fix race in GetOpenDocumentInCurrentContextWithChanges #34195

Conversation

jasonmalinowski
Copy link
Member

@jasonmalinowski jasonmalinowski commented Mar 16, 2019

This was reading Workspace.CurrentSolution twice, so if the document was removed between two reads it'd end up throwing exceptions or triggering asserts.

Fixes #33652

Ask Mode template

Customer scenario

Sometimes when you're using C# or VB code in Visual Studio and you have code lens on, it'll crash.

Bugs this fixes

#33652

Workarounds, if any

Turning off CodeLens will reduce the risk.

Risk

Zero. Trivial bug fix that closes a race.

Performance impact

Zero.

Is this a regression from a previous update?

Yes, ish. The bug has existed for ages, but some changes in 16.0 has probably made it easier to hit.

Root cause analysis

There's a longstanding race in a common helper function that's used in almost every Roslyn feature. The race can happen if a thread is updating the state of our projects while another thread is calling this function. I suspect we've never really noticed this because usually those were always both the UI thread. But in 16.0, we:

  1. Refactored some Code Lens stuff; I haven't checked but this means this function is currently being called on a background thread, and it's possible that moved and is more likely to be hit.
  2. Refactored our project system handling, which means our project state can also be updated on a background thread.

How was the bug found?

Internal automated test runs.

This was reading Workspace.CurrentSolution twice, so if the document
was removed between two reads it'd end up throwing exceptions or
triggering asserts.
@jasonmalinowski
Copy link
Member Author

Turns out this fixes #33652.

@sharwell
Copy link
Member

@jasonmalinowski I believe this occurred while testing in a 16.0 branch. It might be worth taking there since it's also one of our top hitters in integration tests.

@sharwell
Copy link
Member

Integration test failure was caused by #34197. Re-running...

@jasonmalinowski
Copy link
Member Author

jasonmalinowski commented Mar 16, 2019

@sharwell, taking this in 16.0 would mean seeking QB approval and I'm not sure it meets the bar there since it's product code changing. It is undoubtedly a bug, but and the risk of the fix is zero though.

@jinujoseph let's discuss this on Monday. I don't have a strong feeling of where we take this, but the bar application is pretty weird in this case.

@CyrusNajmabadi

This comment has been minimized.

@jinujoseph
Copy link
Contributor

@jasonmalinowski can you fill out the ask mode template and let's do a barcheck for 16.0

@jasonmalinowski jasonmalinowski modified the milestones: 16.1.P1, 16.0 Mar 18, 2019
@jasonmalinowski jasonmalinowski changed the base branch from master to dev16.0 March 18, 2019 14:49
@jasonmalinowski
Copy link
Member Author

@jinujoseph: moved this back to dev16.0 and filled out the ask mode template. I'm for taking it, if only because the risk of not fixing it is greater than the risk of fixing it. (i.e. this is negative risk!)

@jasonmalinowski jasonmalinowski merged commit 559630b into dotnet:dev16.0 Mar 19, 2019
@jasonmalinowski jasonmalinowski deleted the fix-race-in-getopendocumentincurrentcontextwithchanges branch March 19, 2019 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants