-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
SafeHandle marshalling broken with Mono #82308
Comments
That's definitely a miss on my part. Though I'm also surprised nothing has failed until now, so maybe there's more going on. Simplest fix is to just change the ifdef in SafeHandle.cs to make that additional debugging logic exclusive to coreclr. |
We have a CI job that runs tests with The problem doesn't sound architecture specific. I don't know why it doesn't show this issue. 🤔 |
The additional code I added to SafeHandle is under DEBUG and is in corelib; it wouldn't affect a Release runtime. |
Ah, I wrongly assumed |
As of #80715, many
System.Net.Sockets.Tests
test fail with the error:Looking at the behavior with strace shows the error is caused by failed attempts to bind to file descriptor 0 (which is of course not a socket):
Investigating this closer shows that the bind call happens via a P/Invoke in the new test infrastructure:
runtime/src/libraries/Common/tests/System/Net/Sockets/SocketTestExtensions.cs
Lines 205 to 206 in 65f5ad0
This seems to trigger marshalling code in Mono that accesses the
IntPtr
wrapped by theSafeHandle
:runtime/src/mono/mono/component/marshal-ilgen.c
Lines 1919 to 1923 in 65f5ad0
using the data structure here:
runtime/src/mono/mono/metadata/class-internals.h
Lines 670 to 678 in 65f5ad0
However, as of #71991 the definition of the
SafeHandle
type on the managed side is:runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SafeHandle.cs
Lines 24 to 35 in 65f5ad0
Note when the library is built for the Debug configuration, the layout no longer matches - in the place Mono expects the
handle
field, we now have the_ctorStackTrace
field. As this is usually null, we get 0 as file descriptor ...@stephentoub I see you updated the matching CoreCLR definition with #71991, but not the Mono definition. I guess this should be done there as well - however I'm not clear how to do this only for the Debug version of the library, this is something the Mono runtime doesn't currently appear to be doing ...
Also, I was quite confused why this problem only shows up in this one test, and not for all the "normal" places in the library where
SafeHandles
are marshalled to native code. I now see this is using a different mechanism:runtime/src/libraries/Common/src/Interop/Unix/System.Native/Interop.Bind.cs
Lines 12 to 13 in 65f5ad0
which doesn't trigger the Mono marshalling code, but generates IL that uses calls to
System.Runtime.InteropServices.SafeHandle:DangerousGetHandle
instead of accessing the handle at a hard-coded offset.CC @antonfirsov @vargaz @omajid @tmds
The text was updated successfully, but these errors were encountered: