-
Notifications
You must be signed in to change notification settings - Fork 5k
[mono] Disable unsupported apply update scenarios #55698
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
Conversation
@thaystg Do the debugger changes make sense? @stephentoub I think this matches the scenarios we discussed. @mikem8361 I think this is consistent with what CoreCLR does? |
The second two bullets. I'm not sure what the first bullet means? |
I think the first bullet is more of a technical point (in case I messed up the first two). In the core hot reload method, I keep track of whether we are called due to a debugger command or due to a call to the managed ApplyUpdate API and throw an exception if we see a mix of the two. The other two changes should prevent that from ever happening, but it seemed easy and harmless to add an extra check. |
Got it. Sounds right then. Thanks. |
I know it is late, but your logic looks good and follows coreclr's. |
ApplyUpdate
and debugger protocol apply updateApplyUpdate
has been calledApplyUpdate
if debugger is attachedNote that I didn't do the last 2 changes on wasm, since the debugging there doesn't fully work yet and it would impede further work to disable stuff now.
Fixes #55228, contributes to #44806