[mono][interp] Resolve virtual method on delegates created by compiled code by BrzVlad · Pull Request #101168 · dotnet/runtime

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad · 2024-04-17T08:13:22Z

Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

Fixes#101074

…d code Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

dotnet-policy-service · 2024-04-17T08:13:46Z

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

simonrozsival · 2024-04-18T08:34:37Z

We should backport this fix to a .NET 8 servicing release

simonrozsival · 2024-04-18T13:34:56Z

/cc @vitek-karas

vitek-karas · 2024-04-18T14:07:17Z

+1 on backporting. @BrzVlad how risky is this fix for servicing?

BrzVlad · 2024-04-18T15:54:54Z

I think it is rather low risk (but not 100% risk free as I would have considered all my previous backports in general). The main problem is that we don't have good testing for this code path.

simonrozsival · 2024-04-19T13:03:29Z

/backport to release/8.0-staging

github-actions · 2024-04-19T13:03:40Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8754040309

vitek-karas · 2024-04-19T14:02:01Z

@BrzVlad Sorry for not understanding the code change, so I'm going to ask: The new behavior will kick in only for the cases which would fail otherwise, or would it also be used in some cases which already work today and this might change that behavior?

BrzVlad · 2024-04-23T07:21:44Z

@vitek-karas So long story short, if the delegate is created by code that doesn't handle interp related initialization (when jit inlines some delegate initialization) we hit this path in interpreter when first invoking the delegate. What this change does is when that first invoke happens and the method is virtual we resolve the virtual method on the target object. So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

simonrozsival · 2024-04-23T09:06:51Z

So, in theory, there could have been cases where this code was calling the correct method by chance and after now resolving the virtual method something unexpected could happen, but I would say the chance is very low.

@BrzVlad so does this mean that there could be a case like

class BaseClass
{
public virtual int GetValue() => 1;
}
class DerivedClass : BaseClass
{
public override int GetValue() => 2;
}

where the developer would call a delegate for inst.GetValue and they would be getting 1 because of the bug and their code would expect this behavior, and after this change, it will break because it will start returning 2?

BrzVlad · 2024-04-23T09:17:19Z

I wouldn't really worry about cases like that. I was rather saying that maybe in your case, the target object is a BaseClass so BaseClass.GetValue is the correct method to call, but with the fix a virtual method lookup happens on the target object, and maybe something unexpected can happen here. I can't pinpoint something specific, it is unlikely for something to break, just saying.

…d code (dotnet#101168) Creating a delegate would normally end up calling into the runtime via ves_icall_mono_delegate_ctor. However, jit/aot backand have a fastpath where the delegate is not fully initialized (relying on the delegate trampoline to resolve the actual method to be called when the delegate is first called). Interp delegate initialization therefore doesn't take place. If this is the case and the delegate method is virtual, we would need to resolve it based on the target object.

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

BrzVlad requested a review from kotlarmilos as a code owner April 17, 2024 08:13

ghost added the area-Codegen-Interpreter-mono label Apr 17, 2024

dotnet-policy-serviceBot assigned BrzVlad Apr 17, 2024

kotlarmilos approved these changes Apr 17, 2024
View reviewed changes

lewing merged commit 2fe9b3b into dotnet:mainApr 17, 2024

This was referenced Apr 17, 2024
Timeout in System.Text.Json.Tests.Utf8JsonWriterTests.WriteNumbers #101193
Closed
[browser] RuntimeError: memory access out of bounds #96546
Closed

github-actionsBot mentioned this pull request Apr 19, 2024
[release/8.0-staging] [mono][interp] Resolve virtual method on delegates created by compiled code #101290
Merged
4 tasks

github-actionsBot locked and limited conversation to collaborators May 24, 2024

Uh oh!

Conversation

BrzVlad commented Apr 17, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

vitek-karas commented Apr 18, 2024

Uh oh!

BrzVlad commented Apr 18, 2024

Uh oh!

simonrozsival commented Apr 19, 2024

Uh oh!

github-actionsBot commented Apr 19, 2024

Uh oh!

vitek-karas commented Apr 19, 2024

Uh oh!

BrzVlad commented Apr 23, 2024

Uh oh!

simonrozsival commented Apr 23, 2024

Uh oh!

BrzVlad commented Apr 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

BrzVlad commented Apr 17, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

vitek-karas commented Apr 18, 2024

Uh oh!

BrzVlad commented Apr 18, 2024

Uh oh!

simonrozsival commented Apr 19, 2024

Uh oh!

github-actionsBot commented Apr 19, 2024

Uh oh!

vitek-karas commented Apr 19, 2024

Uh oh!

BrzVlad commented Apr 23, 2024

Uh oh!

simonrozsival commented Apr 23, 2024

Uh oh!

BrzVlad commented Apr 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

BrzVlad commented Apr 17, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

simonrozsival commented Apr 18, 2024

Uh oh!

vitek-karas commented Apr 18, 2024

Uh oh!