-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
CoreCLR's debug/checked last error trashing leaks in non-P/Invoke scenarios #59721
Comments
Is there nothing else in these methods that would modify the last error on some paths in these cases? The last error is very volatile. You have to explicitly save it if you want to preserve it. |
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsCoreCLR has a macro named However, it leaks out in a number of non-P/Invoke scenarios, which impacts some of the DllImportGenerator tests that use DNNE to make the logic of the native side of the generated code tests implemented in managed code. This causes test failures with a Debug/Checked runtime since the expected error code is not set since CoreCLR sets an error code value and leaves it set. For example, it leaks out of
|
Agree. We chatted about this issue offline. We thought it warranted an issue for tracking purposes when using the hosting APIs. The impetus for this was around using DNNE in a test scenario and is being addressed in AaronRobinsonMSFT/DNNE#87. /cc @elinor-fung |
Is it really just a DNNE problem? I would expect you have to make fixes in the runtime as well to make this work 100%. |
I believe so. The issue here is DNNE discovers the export lazily so the initial call via a P/Invoke looks like:
Where as all subsequent ones look like the following:
For DNNE, preserving the current error code during "Discover export" should address the stated behavior. Are you thinking of another scenario where this could manifest? |
I think from the .NET Hosting API perspective, |
Do prologs and epilogs of UnmanagedCallersOnly methods preserve the last error in all situations? |
I don't think it is and I believe we want that in this case. Or are you referring to the case where transitioning itself may cause last error to be impacted? |
I consider transitioning itself (e.g. the call to
|
CoreCLR has a macro named
TRASH_LASTERROR
in utilcode that is used to make it easier to detect when the "last system error code" is not preserved in P/Invoke scenarios.However, it leaks out in a number of non-P/Invoke scenarios, which impacts some of the DllImportGenerator tests that use DNNE to make the logic of the native side of the generated code tests implemented in managed code. This causes test failures with a Debug/Checked runtime since the expected error code is not set since CoreCLR sets an error code value and leaves it set.
For example, it leaks out of
coreclr_create_delegate
's calls toStringToUnicode
, as well asComponentActivator
's calls toMarshal.PtrToStringAuto
.The text was updated successfully, but these errors were encountered: