-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Add ICorDebugHeapValue4 -- CreatePinnedHandle #44471
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.
Otherwise LGTM
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
b33db21
to
a122ca3
Compare
Thanks @sdmaclea! LGTM, though I'm not too familiar with adding APIs in this area. |
Tagging subscribers to this area: @tommcdon Issue meta data
|
@kouvel I expect when you have the rest of the tiered JIT, data breakpoint deadlock fix finished. You will backport the whole fix to 5.0 servicing branch. |
Yep about to put up a PR for my side shortly, will port both once that's in |
…ding in some cases 1. When suspending for the debugger is in progress (the debugger is waiting for some threads to reach a safe point for suspension), a thread that is not yet suspended may trigger another runtime suspension. This is currently not allowed because the order of operations conflicts with requirements to send GC events for managed data breakpoints to work correctly when suspending for a GC. Instead, the thread suspends for the debugger first, and after the runtime is resumed, continues suspending for GC. 2. At the same time, if the thread that is not suspended yet is in a forbid-suspend-for-debugger region, it cannot suspend for the debugger, which conflicts with the above scenario, but is currently necessary for the issue fixed by dotnet#40060 3. The current plan is to change managed data breakpoints implementation to pin objects instead of using GC events to track object relocation, and to deprecate the GC events APIs 4. With that, the requirement in #1 goes away, so this change conditions the check to avoid suspending the runtime during a pending suspension for the debugger when GC events are not enabled - Verified that the latest deadlock seen in dotnet#42375 manifests only when a data breakpoint set and not otherwise - Combined with dotnet#44471 and a VS update to use that to switch to the pinning mechanism, the deadlock issue seen above should disappear completely
* Add ICorDebugHeapValue4 * Add EnableGCNotificationEvents deprecation comment
#44563) * Add ICorDebugHeapValue4 -- CreatePinnedHandle (#44471) * Add ICorDebugHeapValue4 * Add EnableGCNotificationEvents deprecation comment * Drop support for IID_ICorDebugProcess10 and fix thread suspend logic (#44549) * Stop providing IID_ICorDebugProcess10 Prevent older VS versions from setting managed data breakpoints. * Simplify the thread collision logic to prevent deadlock This is a simplification of #44539 as proposed by @kouvel
No description provided.