-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Suspected CodeGen Bug in a User-Defined AsyncMethodBuilder #104274
Comments
Why do you believe there's a codegen bug? You say "_Task = task;" is a nop, but is what you really mean that it's not actually being stored into your state machine? I would expect that's because you're storing it into the wrong one. By the time you get to the _Task = task line, you've already copied the state machine into your Continuation type... the _Task field you're storing into isn't the same one as is in the Continuation. (In https://devblogs.microsoft.com/dotnet/how-async-await-really-works/, search for "Now comes a somewhat mind-bending step" for related discussion.) |
I've observed that this issue generates new code in the newer versions of the .NET runtime. If this were a programming error, I would expect to see the corresponding code for However, with the newer runtime, I've found that there are no issues under the debug configuration, but the problem persists under the release configuration. You might be right regarding the specific implementation issues of AsyncMethodBuilder that you mentioned. But the current phenomenon indeed reflects a bug. |
Tested with 8.0.6. The same piece of code works fine in Debug configuration, but throws NRE in Release. Probably a codegen bug. |
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
The underlying state machine is emitted as a class by Roslyn under debug configuration. In release, it is emitted as a struct. Thus, I don't see any JIT issues here -- in debug no NRE is thrown. In release, the NRE is thrown whether or not the JIT is optimizing ( |
Tagging subscribers to this area: @dotnet/area-system-threading-tasks |
FWIW I had encountered a very similar bug with a custom async method builder that fails only in Release mode, which I fixed in teo-tsirpanis/uom@98c951f. From what @stephentoub said, it's likely a matter of wrong assignment order in
Doing this might require some additional refactoring in your code. |
This issue has been marked |
Description
There appears to be a CodeGen bug within the
SuspendTaskAsyncMethodBuilder.Start
method. The assignment_Task = task;
is erroneously emitted as a no-op. Note that changingSuspendTaskAsyncMethodBuilder
from a value type (struct
) to a reference type (class
) results in the program running correctly.Reproduction Steps
Expected behavior
Actual behavior
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: