-
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
[mono] [imt] Don't increment vt_slot for non-virtual generic methods #94437
Conversation
Interfaces can have static generic methods, for example. They don't have a vt_slot. When building an IMT slot, we need to collect all the interface methods that map to a particular IMT slot along with their implementing vtable entries. To do that, vt_slot starts at the interface offset of a particular interface and keeps incrementing as we iterate over the methods of the interface. It is crtitical that vt_slot is accurate - otherwise we may dispatch the interface call to the wrong virtual method.
the extra_interfaces argument was used to implement additional interfaces on cross-domain transparent proxy objects.
It's frustrating that we have to do this manual counting of runtime/src/mono/mono/metadata/class-init.c Lines 3608 to 3620 in 5184067
I'm not actually convinced that |
two curl failures in the mono lanes
|
This comment was marked as outdated.
This comment was marked as outdated.
/backport to release/7.0-staging |
This comment was marked as outdated.
This comment was marked as outdated.
/backport to release/6.0-staging |
Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/6786091607 |
Started backporting to release/6.0-staging: https://github.com/dotnet/runtime/actions/runs/6786093881 |
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/6786100723 |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
@lambdageek I'm going to apply this change to dotnet/dotnet release/8.0.1xx, run the aspnetcore test suite against it, and share the results. It will take about 4 hours (if all goes well). |
I'm going to try one more idea to get make a test case for this (basically try to force an IMT collision by having 20 interface methods (since there are 19 slots)) |
This comment was marked as outdated.
This comment was marked as outdated.
/backport to release/8.0-staging |
/backport to release/7.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/6788024658 |
Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/6788026251 |
The ef core issue is fixed by this. There are still about a 100 failures with mono on x64. This
The SignalR tests show another issue that is vtable related. It's not a regression caused by this PR (the tests are also failing with the rc2 build).
If I understand #93770 (comment) correctly all these tests were passing with preview6. We can investigate these further independent of this PR. |
This code is probably responsible: runtime/src/mono/System.Private.CoreLib/src/System/Reflection/CustomAttribute.cs Lines 159 to 165 in 952ac21
and apparently I think this is worth a separate issue.
I'm not getting anywhere with this one... I can't even find |
|
Created #94488 for the |
Created #94490 for the VTable fail |
…rtual generic methods (#94478) Backport of #94437 to release/6.0-staging Fixes #93770 * [mono] [imt] Don't increment vt_slot for non-virtual generic methods Interfaces can have static generic methods, for example. They don't have a vt_slot. When building an IMT slot, we need to collect all the interface methods that map to a particular IMT slot along with their implementing vtable entries. To do that, vt_slot starts at the interface offset of a particular interface and keeps incrementing as we iterate over the methods of the interface. It is crtitical that vt_slot is accurate - otherwise we may dispatch the interface call to the wrong virtual method. * [mono][imt] remove dead appdomain code the extra_interfaces argument was used to implement additional interfaces on cross-domain transparent proxy objects. * [mono][imt] fixup ifdefed debug code * Add test case
…rtual generic methods (#94468) Backport of #94437 to release/7.0-staging Fixes #93770 * [mono] [imt] Don't increment vt_slot for non-virtual generic methods Interfaces can have static generic methods, for example. They don't have a vt_slot. When building an IMT slot, we need to collect all the interface methods that map to a particular IMT slot along with their implementing vtable entries. To do that, vt_slot starts at the interface offset of a particular interface and keeps incrementing as we iterate over the methods of the interface. It is crtitical that vt_slot is accurate - otherwise we may dispatch the interface call to the wrong virtual method. * [mono][imt] remove dead appdomain code the extra_interfaces argument was used to implement additional interfaces on cross-domain transparent proxy objects. * [mono][imt] fixup ifdefed debug code * Add test case --------- Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
Interfaces can have static generic methods, for example. They don't have a
vt_slot
.When building an IMT slot, we need to collect all the interface methods that map to a particular IMT slot along with their
implementing vtable entries. To do that,
vt_slot
starts at the interface offset of a particular interface and keeps incrementing as we iterate over the methods of the interface. It is crtitical thatvt_slot
is accurate - otherwise we may dispatch the interface call to the wrong virtual method.Fixes #93770
Also remove the
extra_interfaces
argument frombuild_imt_slots
- it was used only for appdomain support (transparent proxy objects implemented extra interfaces).Also fixup some ifdef'd debugging code.