[release/6.0] Fix frequent FuncEval abort upon hitting a breakpoint in an ASP.NET Core web app #58218
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…ore web app - `AssemblySpecBindingCache` uses a cooperative-GC-mode data structure for the cache and operates on the cache from inside a lock taken in preemptive-GC-mode - So when the cache is being used, cooperative-GC-mode is entered while holding the lock, which can in turn suspend for the debugger. Then a FuncEval that also happens to operate on the cache would deadlock on acquiring the lock and would have to be aborted. - This seems to be happening very frequently when hitting an early breakpoint in a default new ASP.NET Core web app in .NET 6 when hot reload is enabled - Fixed by using the same solution that was used for the slot backpatching lock. When cooperative-GC-mode would be entered inside the lock, a different lock holder based on `CrstAndForbidSuspendForDebuggerHolder` is used, which prevents the thread from suspending for the debugger while the lock is held. The thread would instead suspend for the debugger after leaving the forbid region after releasing the lock.
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
hoyosjs
approved these changes
Aug 26, 2021
jeffschwMSFT
approved these changes
Aug 26, 2021
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #58217 to release/6.0
/cc @kouvel
Customer Impact
On a new ASP.NET Core web app project targeting .NET 6 with hot reload enabled (enabled by default), a breakpoint on the first line in Main, F5 hits the breakpoint and frequently hits a race condition where a FuncEval is unable to evaluate one of the locals due to a deadlock, and has to be aborted with an error message. The race condition may occur at any time when the debugger attach/break occurs during a short window of time where an assembly is being loaded, it just happens to be hitting that timing frequently in some cases.
Testing
Manual testing with the frequent repro above.
Risk
Low - The same solution is already used for the slot backpatching lock to fix the same type of deadlock.