Move the return var out of liveLocalsIntervals#127931
Merged
Merged
Conversation
Member
Author
|
/azp run runtime-libraries-interpreter |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @BrzVlad, @janvorli, @kg |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes interpreter async continuation state capture so the awaited call’s return value is no longer treated as a normal “live local” to copy into the continuation object (which previously could copy uninitialized stack data and lead to GC consistency crashes in interpreter mode). Instead, it tracks return-value metadata separately and restores the return value explicitly during the resume path.
Changes:
- Exclude the call return-value var from
liveVarswhen emitting async suspend data, and record dedicated return-value metadata (size+ stack offset) inInterpAsyncSuspendData. - Adjust interpreter continuation suspend/resume copy logic so live locals are copied after the continuation’s result storage region, and explicitly copy the return value from
GetResultStorage()back to the interpreter stack on resume. - Add fixup logic so the stored “return value var” is patched from var index to final stack offset during interval-map finalization.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/coreclr/vm/interpexec.cpp | Shifts live-local copy region past result storage; adds explicit return-value restore on resume. |
| src/coreclr/interpreter/inc/interpretershared.h | Extends InterpAsyncSuspendData with return-value continuation size and stack offset metadata. |
| src/coreclr/interpreter/compiler.cpp | Stops treating return-value var as a live var; computes/stores return-value metadata and patches it during interval-map update. |
When generating an async call, in EmitSuspend, we obtain the set of vars that are alive at this point in time and we store this information inside the suspenData. If they async call needs to suspend it will store these vars into the ContinuationObject, with their values being restored when we resume the continuation. Previous code would store the result value as well into the ContinuationObject. The problem is that this would lead to storing uninitialized data into the object, which can result in random GC crashes. This commit removes the result var from the set of live vars, stores associated information specifically for the return var inside the suspend data and we make use of this information to write the result only on the suspend resume path.
BrzVlad
force-pushed
the
fix-clrinterp-async-ret
branch
from
94adc6a to
0dc387b
Compare
This was referenced May 8, 2026
Open
janvorli
reviewed
May 11, 2026
BrzVlad
added a commit
that referenced
this pull request
May 21, 2026
…by the method (#128403) Consider the scenario where we are emitting an async method call where the return value is not used at all by the method and, by the time we are actually doing the suspend operation, a new live variable is created. This means that the new variable could share the same offset as the return offset. Example interp IR: ``` IR_0074: call [64 <- 96], .Program:ThrowsAsync[System.__Canon](System.Func`1[System.Threading.Tasks.Task]) // var at offset 56 was present on the interp execution stack and it gets moved to a temporary that shares the same offset with the dead return // this means that, when we restore the context and write the continuation return to the interp stack, we overwritte this IR_0078: mov.8 [64 <- 56], IR_007b: handle.continuation [72 <- nil], AsyncSuspendData[continuationTypeHnd=0x7fff7980c310, flags=3144, liveLocalsIntervals=[{64, 71},], zeroedLocalsIntervals=[], keepAliveOffset=32], 0x7fff797479c0 (CORINFO_HELP_ALLOC_CONTINUATION)(indirect) IR_007f: capture.context.on.suspend [80 <- 72], AsyncSuspendData[continuationTypeHnd=0x7fff7980c310, flags=3144, liveLocalsIntervals=[{64, 71},], zeroedLocalsIntervals=[], keepAliveOffset=32] IR_0083: restore.contexts.on.suspend [72 <- 72 0 16], AsyncSuspendData[continuationTypeHnd=0x7fff7980c310, flags=3144, liveLocalsIntervals=[{64, 71},], zeroedLocalsIntervals=[], keepAliveOffset=32] IR_0089: handle.continuation.suspend [nil <- 72], AsyncSuspendData[continuationTypeHnd=0x7fff7980c310, flags=3144, liveLocalsIntervals=[{64, 71},], zeroedLocalsIntervals=[], keepAliveOffset=32] IR_008c: handle.continuation.resume [nil <- nil], AsyncSuspendData[continuationTypeHnd=0x7fff7980c310, flags=3144, liveLocalsIntervals=[{64, 71},], zeroedLocalsIntervals=[], keepAliveOffset=32] IR_008e: ldind.i8 [96 <- 64], 8 ``` This bug was exposed by #127931, which changed the order of the write to the result var, during resume. --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
This file contains hidden or 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
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.
When generating an async call, in EmitSuspend, we obtain the set of vars that are alive at this point in time and we store this information inside the suspenData. If they async call needs to suspend it will store these vars into the ContinuationObject, with their values being restored when we resume the continuation.
Previous code would store the result value as well into the ContinuationObject. The problem is that this would lead to storing uninitialized data into the object, which can result in random GC crashes. This commit removes the result var from the set of live vars, stores associated information specifically for the return var inside the suspend data and we make use of this information to write the result only on the suspend resume path.
Fixes #127855