Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

The added test has successfully passed on CI.

This is safe to be merged.

@ivanpovazan @lambdageek did this get Tactics approval? Today is code complete.

I'm flowing staging to internal now, so the branches are closed. This will have to wait until the January release.

Per tactics, this change unfortunately doesn't meet the bar in terms of customer impact. @ivanpovazan if you find this blocks customers in a significant way, please identify and reopen.

@steveisok This affects the ASP.NET Core request handling on RHEL builds of .NET for ppc64le and s390x.
It would be preferable to backport this upstream rather than Red Hat adding it as a patch in our builds.
Only backporting to .NET 8 is good for us.

I echo Tom's comments -- will be good to have it back ported to .NET 8

If you would like to see this backported, it needs to be justified by a concrete customer-centric statement. What is the concrete ASP.NET or Mobile scenario that is impacted by this issue? How likely is it for customers to hit the issue? Are there workarounds?

ASP.NET test suite failing is not a good justification for a backport. It is why the backport was rejected by tactics.

I think one possible (and simple) workaround would be to intercept calling the parameterless extension method GetCustomAttributes by defining the parameterless variant of the method in the custom attribute provider it self https://github.com/dotnet/aspnetcore/blob/402e7fc10aa304775f50d318c8a4dafbf46dbfe0/src/Shared/PropertyAsParameterInfo.cs#L15

public object[] GetCustomAttributes() => GetCustomAttributes(true);

Explanation

If we take one of the tests that were reported as crashing:

1. A test requests creating a delegate through RequestDelegateFactory https://github.com/dotnet/aspnetcore/blob/83947bf3bc084c8f6655c5cbd07d2f7bc2fbd928/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs#L1184
2. This ends up calling the extension method System.Reflection.CustomAttributeExtensions.GetCustomAttributes(this ParameterInfo element) on a custom ParameterInfo
   https://github.com/dotnet/aspnetcore/blob/83947bf3bc084c8f6655c5cbd07d2f7bc2fbd928/src/Http/Http.Extensions/src/RequestDelegateFactory.cs#L701
3. The extension method further calls System.Attribute.GetCustomAttributes(ParameterInfo element)
   

   runtime/src/libraries/System.Private.CoreLib/src/System/Reflection/CustomAttributeExtensions.cs

   Lines 77 to 79 in f59ef7f

   	public static IEnumerable<Attribute> GetCustomAttributes(this ParameterInfo element)
   	{
   	return Attribute.GetCustomAttributes(element);

4. Which finally calls the problematic API which does not handle the custom attribute provider correctly System.Reflection.CustomAttribute.GetCustomAttributes(ICustomAttributeProvider obj, Boolean inherit) in:

   runtime/src/mono/System.Private.CoreLib/src/System/Attribute.Mono.cs

   Line 47 in f59ef7f

   public static Attribute[] GetCustomAttributes(ParameterInfo element) => (Attribute[])CustomAttribute.GetCustomAttributes(element, true);

   
   NOTE: inherit parameter defaults to true in this path.

With the provided workaround we would intercept the step 2) and instead directly call the locally defined override https://github.com/dotnet/aspnetcore/blob/402e7fc10aa304775f50d318c8a4dafbf46dbfe0/src/Shared/PropertyAsParameterInfo.cs#L158
whose implementation invokes GetCustomAttributes on the base types (which work correctly).

@tmds @janani66 Would this be a viable workaround for you?

@ivanpovazan do you know if the test failures indicate product bugs?

The backport request is closed assuming it will only address test failures and not actual product bugs.

If we can demonstrate these are relevant product bugs, the decision to backport can be revisited.

@ivanpovazan do you know if the test failures indicate product bugs?

They indicate that using a custom attribute provider like: internal sealed class PropertyAsParameterInfo : ParameterInfo and GetCustomAttributes API with Mono can cause runtime failures.

However, I am not sure how common such pattern is, as it would have been reported before.
Additionally, as far as I know, there weren't any dotnet/runtime unit tests covering such usage (tests were added with the fix), which indicates this bug existed for some time (for what its worth, the original issue is reproducible with .NET7 as well).