StackOverflow when binding library containing class with base type set to itself

[entdark]

Android application type

Classic Xamarin.Android (MonoAndroid12.0, etc.)

Affected platform version

VS 2019 16.11.12, VS for Mac 17.0.7, VS for Mac 17.3.1

Description

I updated a library that I wanted to bind and the new library required dependency of Xamarin.GooglePlayServices.AppSet that targets Android 12. So I had to switch from Android 11 to Android 12 target and thus switched from JDK 8 to JDK 11.
And the library fails to get compiled.
Before the update it had no dependencies and got compiled with Android 11 target just fine.

Logs:
YandexMetrica_build_log_macos_22.08.2022.txt
YandexMetrica_build_log_22.08.2022.txt

Steps to Reproduce

To reproduce the issue try to build the project of question yourself.
The Android binding library project: https://github.com/entdark/Xamarin.AppMetrica/tree/appmetrica-5.0.0
Make sure you compile from the appmetrica-5.0.0 branch.

Did you find any workaround?

The workaround has not been found yet.

Relevant log output

Error while processing '[Method] java.time.temporal.Temporal addTo(java.time.temporal.Temporal temporal, long amount)' in '[Class] java.time.temporal.ChronoUnit': Type 'java.time.temporal.Temporal' was not found.

Related issue

dotnet/android#3291

[jpobst]

Actual error from log:

Stack overflow: IP: 0x11ae88918, fault addr: 0x30d984fd8
Stacktrace:
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaClassModel.PrepareGenericInheritanceMapping () [0x00038] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      <...>
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaClassModel.get_GenericInheritanceMapping () [0x00000] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaMethodModel/<>c__DisplayClass47_0.<FindBaseMethod>b__0 (Java.Interop.Tools.JavaTypeSystem.Models.JavaMethodModel) [0x00018] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      at System.Linq.Enumerable.TryGetFirst<TSource_REF> (System.Collections.Generic.IEnumerable`1<TSource_REF>,System.Func`2<TSource_REF, bool>,bool&) [0x0003f] in <80f7dc36b4e24f4b86610a67568d2e19>:0
      at System.Linq.Enumerable.FirstOrDefault<TSource_REF> (System.Collections.Generic.IEnumerable`1<TSource_REF>,System.Func`2<TSource_REF, bool>) [0x00000] in <80f7dc36b4e24f4b86610a67568d2e19>:0
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaMethodModel.FindBaseMethod (Java.Interop.Tools.JavaTypeSystem.Models.JavaClassModel) [0x00028] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaClassModel.ResolveBaseMembers () [0x0002d] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      at Java.Interop.Tools.JavaTypeSystem.Models.JavaTypeCollection.ResolveCollection (Java.Interop.Tools.JavaTypeSystem.TypeResolutionOptions) [0x001d1] in <9ad2a4b0fd014215b74d06fce5575b7a>:0
      at generator.JavaTypeResolutionFixups.Fixup (string,string,Java.Interop.Tools.Cecil.DirectoryAssemblyResolver,string[]) [0x00055] in <a593e50c39a04879937ed01eece67aa3>:0
      at Xamarin.Android.Binder.CodeGenerator.Run (Xamarin.Android.Binder.CodeGeneratorOptions,Java.Interop.Tools.Cecil.DirectoryAssemblyResolver) [0x00230] in <a593e50c39a04879937ed01eece67aa3>:0
      at Xamarin.Android.Binder.CodeGenerator.Run (Xamarin.Android.Binder.CodeGeneratorOptions) [0x0001b] in <a593e50c39a04879937ed01eece67aa3>:0
      at Xamarin.Android.Binder.CodeGenerator.Main (string[]) [0x0000e] in <a593e50c39a04879937ed01eece67aa3>:0
      at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) [0x0002a] in <a593e50c39a04879937ed01eece67aa3>:0

This stack overflow is caused by the class (decompiled):

package com.yandex.metrica.impl.ob;
public class c5<BaseHandler> extends c5<BaseHandler> { ... }

Our tools recursively resolve a type's base type, which in this case is itself, resulting in a stack overflow.

I doubt this is valid Java (?). The library looks obfuscated so I don't know if this is an obfuscation issue.

Unfortunately this happens in the "api xml adjuster" phase, which runs before metadata, so it cannot be fixed with metadata.

[entdark]

Thank you for pointing out where to dig to.

[moljac]

regarding update:

16.0.2 was published 4 months ago
https://www.nuget.org/packages/Xamarin.GooglePlayServices.AppSet
it is the latest version
https://maven.google.com/web/index.html?q=appset#com.google.android.gms:play-services-appset

[entdark]

As we found out the issue was in inability to properly parse out obfuscated Java classes.
In discord I offered to enhance the parser to handle such obfuscated classes but as a reply I got: "it's a cat and mouse game" where a fix gets added and they add more obfuscated features and so on.

But I still insist on improving current parser for 2 reasons:

• such issues will appear in the future again and we at least know 2 exact cases that can be handled
• I don't think Xamarin is such a big "mouse" they would like to "chase"

It's probably better to make another issue to track that if you agree with my suggestions.

[jpobst]

Although we do not want to commit to fixing every possible invalid Java input, we're going to fix this one because:

• It's an easy fix
• A StackOverflow on a bad input is a very bad result
• Clearly there is an active Java obfuscator out there producing this pattern