Fix GC hole with collectible assemblies and tailcalls #51315
Merged
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.
We must take special care to keep the tailcall dispatcher targets alive
while tailcalls are in-flight. In particular, given the following
callstack:
[B]M2()
[SPC]DispatchTailCalls
[A]M()
it could happen that [B]M2() queued a tail call to a function [B]M3().
Since there is a live dispatcher on the call stack, this would result in
[B]M2() storing a function pointer pointing to [B]M3() and returning to
this dispatcher to let it take care of the tailcall.
If B was loaded in a collectible ALC, it would then be possible for
there to be nothing keeping this ALC alive, and for the assembly to be
unloaded before the dispatcher invoked the function pointer.
I was unable to come up with a test case where this happened without
making changes to the dispatcher; the window otherwise seems to be too
small. To reproduce the problem I thus had to add a Thread.Sleep(50)
into the dispatcher, which quickly resulted in an
AccessViolationException in the scenario above. With the changes in this
commit I was then no logner able to reproduce the problem.
Fix #41314