Skip to content

Fixed mono from gc handle #62071

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.

Sign up for GitHub

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

Closed
srxqds wants to merge 4 commits into from
Closed

Fixed mono from gc handle #62071

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ceac159
mono_runtime_delegate_invoke wrapper with MONO_ENTER_GC_UNSAFE/MONO_E…
srxqds Nov 24, 2021
a56b0cf
Update object.c
srxqds Nov 24, 2021
3de69c4
Merge branch 'dotnet:main' into main
srxqds Nov 24, 2021
6590fe7
Update AssemblyLoadContext.Mono.cs
srxqds Nov 26, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/mono/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.Mono.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@

namespace System.Runtime.Loader
{
[StructLayout(LayoutKind.Sequential)]
Copy link
Member

@lateralusX lateralusX Nov 26, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this construction is a little problematic and you see the symptoms of it. Just adding LayoutKind.Sequential might fix it, but depending on sequential field order in a partial class that is in this case not even sealed, so don't know what guarantees that will give you of complete class layout. You can also see that CoreCLR depends on a different order, that is not inline with how the fields are declared, but how they are layed out by loader. I believe a better way to fix it is to get rid of MonoManagedAssemblyLoadContext and fix mono_alc_from_gchandle to use a cached offset to the nativeAssemblyLoadContext field and then access it based on the offset instead of depending on field order in the class.

Copy link
Contributor Author

@srxqds srxqds Nov 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, thank you, i will try later

public partial class AssemblyLoadContext
{
internal IntPtr NativeALC
Expand Down
15 changes: 8 additions & 7 deletions src/mono/mono/metadata/object.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3714,24 +3714,25 @@ mono_get_delegate_end_invoke_checked (MonoClass *klass, MonoError *error)
MonoObject*
mono_runtime_delegate_invoke (MonoObject *delegate, void **params, MonoObject **exc)
Copy link
Member

@lateralusX lateralusX Nov 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove all changes of mono_runtime_delegate_invoke from this PR, this is duplicate change of #62003.

{
MONO_REQ_GC_UNSAFE_MODE;

ERROR_DECL (error);
MonoObject* result = NULL;
MONO_ENTER_GC_UNSAFE;
if (exc) {
MonoObject *result = mono_runtime_delegate_try_invoke (delegate, params, exc, error);
result = mono_runtime_delegate_try_invoke (delegate, params, exc, error);
if (*exc) {
mono_error_cleanup (error);
return NULL;
result = NULL;
} else {
if (!is_ok (error))
*exc = (MonoObject*)mono_error_convert_to_exception (error);
return result;
}
} else {
MonoObject *result = mono_runtime_delegate_invoke_checked (delegate, params, error);
result = mono_runtime_delegate_invoke_checked (delegate, params, error);
mono_error_raise_exception_deprecated (error); /* OK to throw, external only without a good alternative */
return result;

}
MONO_EXIT_GC_UNSAFE;
return result;
}

/**
Expand Down