Skip to content

Fix frequent FuncEval abort upon hitting a breakpoint in an ASP.NET Core web app - #58217

Merged
kouvel merged 1 commit into
dotnet:mainfrom
kouvel:DomainCacheCrstDebugFix
Aug 27, 2021
Merged

Fix frequent FuncEval abort upon hitting a breakpoint in an ASP.NET Core web app#58217
kouvel merged 1 commit into
dotnet:mainfrom
kouvel:DomainCacheCrstDebugFix

Conversation

@kouvel

Copy link
Copy Markdown
Contributor
  • 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.

…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.
@kouvelkouvel added the area-AssemblyLoader-coreclr only use for closed issues label Aug 26, 2021
@kouvelkouvel added this to the 7.0.0 milestone Aug 26, 2021
@kouvel
kouvel requested a review from hoyosjsAugust 26, 2021 21:19
@kouvelkouvel self-assigned this Aug 26, 2021
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details
  • 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.
Author:kouvel
Assignees:kouvel
Labels:

area-AssemblyLoader-coreclr

Milestone:7.0.0

@kouvel

Copy link
Copy Markdown
ContributorAuthor

/backport to release/6.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1172057212

Comment threadsrc/coreclr/vm/appdomain.hpp
@kouvel
kouvel merged commit 51ac86c into dotnet:mainAug 27, 2021
@kouvel
kouvel deleted the DomainCacheCrstDebugFix branch August 27, 2021 15:48
@ghostghost locked as resolved and limited conversation to collaborators Sep 26, 2021
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-AssemblyLoader-coreclronly use for closed issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@kouvel@hoyosjs