Skip to content
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

Bump external/Java.Interop from 3a9f770 to cf80deb #13

Closed

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Jan 9, 2023

Bumps external/Java.Interop from 3a9f770 to cf80deb.

Commits
  • cf80deb [Java.Interop.Tools.JavaCallableWrappers] use IMetadataResolver more (#1069)
  • 5c5dc08 [generator] enum map.csv can set @deprecated-since for enum values (#1070)
  • f8d77fa [generator] Better support deprecated property getter/setters. (#1062)
  • 5e6209e [generator] Obsolete&SupportedOSPlatform attributes on enum members (#1066)
  • 15c8879 [generator] Use decl type's @​deprecated-since if < member's (#1068)
  • 525a45d [Java.Interop.Dynamic-Tests] Use Microsoft.CSharp NuGet package (#1067)
  • 149d70f [generator] Refactor enum writing to use SourceWriters (#1063)
  • c2daa9f [Java.Interop.Tools.Cecil] DirectoryAssemblyResolver & File.Exists() (#1065)
  • 8ab9d33 [Java.Interop.Tools.TypeNameMappings] improve `ToJniNameFromAttributesForAndr...
  • 09f8da2 [JavaCallableWrappers] avoid string.Format() (#1061)
  • See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [external/Java.Interop](https://github.com/xamarin/java.interop) from `3a9f770` to `cf80deb`.
- [Release notes](https://github.com/xamarin/java.interop/releases)
- [Commits](dotnet/java-interop@3a9f770...cf80deb)

---
updated-dependencies:
- dependency-name: external/Java.Interop
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file submodules Pull requests that update Submodules code labels Jan 9, 2023
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Jan 13, 2023

Superseded by #16.

@dependabot dependabot bot closed this Jan 13, 2023
@dependabot dependabot bot deleted the dependabot/submodules/external/Java.Interop-cf80deb branch January 13, 2023 08:13
simonrozsival pushed a commit that referenced this pull request Feb 23, 2024
Context: dotnet/java-interop#1165
Context: dotnet/java-interop@005c914
Context: dotnet#8543
Context: dotnet/java-interop@07c7300
Context: dotnet#8625
Context: xamarin/monodroid@e3e4f12
Context: xamarin/monodroid@a04b73b
Context: efbec22

Changes: dotnet/java-interop@8b85462...07c7300

  * dotnet/java-interop@07c73009: [Java.Interop] Typemap support for JavaObject & `[JniTypeSignature]` (dotnet/java-interop#1181)
  * dotnet/java-interop@d529f3be: Bump to xamarin/xamarin-android-tools/main@ed102fc (dotnet/java-interop#1182)
  * dotnet/java-interop@def5bc0d: [ci] Add API Scan job (dotnet/java-interop#1178)
  * dotnet/java-interop@d5afa0af: [invocation-overhead] Add generated source files (dotnet/java-interop#1175)
  * dotnet/java-interop@473ef74c: Bump to xamarin/xamarin-android-tools/main@4889bf0 (dotnet/java-interop#1172)
  * dotnet/java-interop@005c9141: [Java.Interop] Avoid `Type.GetType()` in `ManagedPeer` (dotnet/java-interop#1168)
  * dotnet/java-interop@0f1efebd: [Java.Interop] Use PublicApiAnalyzers to ensure we do not break API (dotnet/java-interop#1170)

(From the "infinite scream" department…)

It started with a desire to remove some linker warnings
(dotnet/java-interop#1165):

	external/Java.Interop/src/Java.Interop/Java.Interop/ManagedPeer.cs(93,19,93,112):
	warning IL2057: Unrecognized value passed to the parameter 'typeName' of method 'System.Type.GetType(String, Boolean)'.
	It's not possible to guarantee the availability of the target type.

dotnet/java-interop@005c9141 attempted to fix this by requiring the
use of "typemaps" mapping Java type signatures to managed types,
replacing e.g.:

	Type            type            = Type.GetType ("Example.Type, AssemblyName", throwOnError: true)!;
	Type[]          parameterTypes  = GetParameterTypes ("System.Int32:System.Int32");
	ConstructorInfo ctor            = type.GetConstructor (ptypes);
	// ctor=Example.Type(int, int) constructor

with (not exactly, but for expository purposes):

	Type            type            = GetTypeFromSignature("crc64…/Type");
	Type[]          parameterTypes  = GetConstructorCandidateParameterTypes ("(II)V");
	ConstructorInfo ctor            = type.GetConstructor (ptypes);
	// ctor=Example.Type(int, int) constructor
	
among other changes.

This was a *significant* change that would alter *Java.Interop*
semantics but *not* .NET Android semantics -- .NET Android uses
`Java.Interop.TypeManager.n_Activate()` (in this repo) for Java-side
"activation" scenarios, not `Java.Interop.ManagedPeer` -- so in an
abundance of caution we did a manual integration test in
dotnet#8543 to make sure nothing broke before
merging it.

Something was apparently "off" in that integration.  (We're still not
sure what was off, or why it was completely green.)

Ever since dotnet/java-interop@005c9141 was merged, every attempt to
bump xamarin/Java.Interop has failed, in a number of ways described
below.  However, instead of reverting dotnet/java-interop@005c9141
we took this as an opportunity to understand *how and why* things
were failing, as apparently we had encountered some *long-standing*
corner cases in How Things Work.

The oversights and failures include:

 1. In order to make the Java.Interop unit tests work in .NET Android,
    the (largely hand-written) Java.Interop test types *also* need to
    participate with .NET Android typemap support, so that there is a
    typemap entry mapping `net/dot/jni/test/GenericHolder` to
    `Java.InteropTests.GenericHolder<T>` and vice-versa.

    dotnet/java-interop@07c73009 updates
    `Java.Interop.Tools.JavaCallableWrappers` to support creating
    typemap entries for `Java.Interop.JavaObject` subclasses,
    introducing a new `TypeDefinition.HasJavaPeer()` extension method.

 2. (1) meant that, for the first time ever, types in
    `Java.Interop-Tests` participated in .NET Android type mapping.
    This *sounds* fine, except that `Java.Interop-Tests` contains
    "competing bindings" for `java.lang.Object`:

        [JniTypeSignature ("java/lang/Object", GenerateJavaPeer=false)]
        partial class JavaLangRemappingTestObject : JavaObject {
        }

 3. (2) means that, for the first time ever, we *could* have the
    typemap entry for `java/lang/Object` map to
    `Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`,
    *not* `Java.Lang.Object, Mono.Android`.

    Arguably a bug, arguably "meh", but this setup triggered some
    never previously encountered error conditions:

 4. `EmbeddedAssemblies::typemap_java_to_managed()` within
    `libmonodroid.so` returns a `System.Type` that corresponds to a
    JNI type.  `typemap_java_to_managed()` has a bug/corner case
    wherein it will only provide `Type` instances from assemblies
    which have already been loaded.

    Early in startup, `Java.Interop-Tests` hasn't been loaded yet, so
    when `java/lang/Object` was mapped to
    `Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`,
    `typemap_java_to_managed()` would return `null`.

    This is a bug/corner case, which is being investigated in
    dotnet#8625.

 5. Calls to `Java.Lang.Object.GetObject<T>()` call
    `Java.Interop.TypeManager.CreateInstance()`, which loops through
    the type and all base types to find a known binding/wrapper.
    Because of (3)+(4), if (when) we try to find the wrapper for
    `java/lang/Object`, we would find *no* mapping.

    This would cause an `JNI DETECTED ERROR IN APPLICATION` *crash*.

    This was due to a "use after free" bug.

    See the "TypeManager.CreateInstance() Use After Free Bug" section.

 6. Once (5) is fixed we encounter our next issue: the
    `Java.InteropTests.JnienvTest.NewOpenGenericTypeThrows()` unit
    test started failing because
    `crc641855b07eca6dcc03.GenericHolder_1` couldn't be found.

    This was caused by a bug in `acw-map.txt` parsing within `<R8/>`.

    See the "`<R8/>` and `acw-map.txt` parsing.`" section.

 7. Once (6) was fixed, (3) caused a *new* set of failures:
    multiple tests started failing because `java/lang/Object` was
    being mapped to the wrong managed type.

    (3) becomes less "meh" and more "definitely a bug".

    See the "Correct `java/lang/Object` mappings" section.

*Now* things should work reliably.


~~ TypeManager.CreateInstance() Use After Free Bug ~~

On 2011-Oct-19, xamarin/monodroid@e3e4f123d8 introduced a
use-after-free bug within `TypeManager.CreateInstance()`:

	JNIEnv.DeleteRef (handle, transfer);
	throw new NotSupportedException (
	        FormattableString.Invariant ($"Internal error finding wrapper class for '{JNIEnv.GetClassNameFromInstance (handle)}'. (Where is the Java.Lang.Object wrapper?!)"),
	        CreateJavaLocationException ());

`handle` *cannot be used* after `JNIEnv.DeleteRef(handle)`.
Failure to do so results in a `JNI DETECTED ERROR IN APPLICATION`
crash; with `adb shell setprop debug.mono.log lref+` set, we see:

	I monodroid-lref: +l+ lrefc 1 handle 0x71/L from thread '(null)'(1)
	D monodroid-gref:    at Android.Runtime.AndroidObjectReferenceManager.CreatedLocalReference(JniObjectReference , Int32& )
	D monodroid-gref:    at Java.Interop.JniRuntime.JniObjectReferenceManager.CreatedLocalReference(JniEnvironmentInfo , JniObjectReference )
	D monodroid-gref:    at Java.Interop.JniEnvironment.LogCreateLocalRef(JniObjectReference )
	D monodroid-gref:    at Java.Interop.JniEnvironment.LogCreateLocalRef(IntPtr )
	D monodroid-gref:    at Java.Interop.JniEnvironment.InstanceMethods.CallObjectMethod(JniObjectReference , JniMethodInfo )
	D monodroid-gref:    …
	…
	I monodroid-lref: -l- lrefc 0 handle 0x71/L from thread '(null)'(1)
	D monodroid-gref:    at Android.Runtime.AndroidObjectReferenceManager.DeleteLocalReference(JniObjectReference& , Int32& )
	D monodroid-gref:    at Java.Interop.JniRuntime.JniObjectReferenceManager.DeleteLocalReference(JniEnvironmentInfo , JniObjectReference& )
	D monodroid-gref:    at Java.Interop.JniObjectReference.Dispose(JniObjectReference& reference)
	D monodroid-gref:    at Android.Runtime.JNIEnv.DeleteLocalRef(IntPtr )
	D monodroid-gref:    at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
	D monodroid-gref:    at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	D monodroid-gref:    at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
	D monodroid-gref:    at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
	D monodroid-gref:    at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
	D monodroid-gref:    …
	D monodroid-gref:
	E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x71  (index 7 in a table of size 7)
	F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x71
	…
	F droid.NET_Test: runtime.cc:630]   native: #13 pc 00000000003ce865  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)

The immediate fix is Don't Do That™; use a temporary:

	class_name = JNIEnv.GetClassNameFromInstance (handle);
	JNIEnv.DeleteRef (handle, transfer);
	throw new NotSupportedException (
	        FormattableString.Invariant ($"Internal error finding wrapper class for '{class_name}'. (Where is the Java.Lang.Object wrapper?!)"),
	        CreateJavaLocationException ());

Unfortunately, *just* fixing the "use-after-free" bug is insufficient;
if we throw that `NotSupportedException`, things *will* break
elsewhere.  We'll just have an "elegant unhandled exception" app crash
instead of a "THE WORLD IS ENDING" failed assertion crash.

We could go with the simple fix for the crash, but this means that in
order to integrate dotnet/java-interop@005c9141 &
dotnet/java-interop@07c73009 we'd have to figure out how to *ensure*
that `java/lang/Object` is bound as `Java.Lang.Object, Mono.Android`,
not `Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`.
(We actually need to do this *anyway*; see the
"Correct `java/lang/Object` mappings" section.  At the time we I was
trying to *avoid* special-casing `Mono.Android.dll`…)

There is a*slightly* more complicated approach which fixes (5)
while supporting (4) `typemap_java_to_managed()` returning null;
consider the `-l-` callstack:

	at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
	at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
	at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
	at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
	at Android.Runtime.JavaSet.Iterator()

This is part of a generic `Object.GetObject<IIterator>()` invocation!
Additionally, because `IIterator` is an interface, in *normal* use
the `type` variable within `TypeManager.CreateInstance()` would be
`Java.Lang.Object, Mono.Android` and then *immediately discarded*
because `Java.Lang.Object` cannot be assigned to `IIterator`.

Moving the type compatibility check to *before* the
`type == null` check fixes *an* issue with `typemap_java_to_managed()`
returning null.


~~ `<R8/>` and `acw-map.txt` parsing.` ~~

There are many ways for Android+Java code to refer to managed types.

For example, consider the following View subclass:

	namespace Example {
	  partial class MyCoolView : Android.Views.View {
	    // …
	  }
	}

Within layout `.axml` files, you can mention an `Android.Views.View`
subclass by:

  * Using the .NET Full Class Name as an element name.

        <Example.MyCoolView />

  * Using the .NET Full Class Name with a *lowercased* namespace
    name as the element name.

        <example.MyCoolView />

  * Use the Java-side name directly.

        <crc64….NiftyView />

Within Fragments, you can also use the *assembly-qualified name*:

	<fragment class="Example.MyCoolView, AssemblyName" />

At build time, all instances of the .NET type names will be
*replaced* with the Java type names before the Android toolchain
processes the files.

The association between .NET type names and Java names is stored
within `$(IntermediateOutputPath)acw-map.txt`, which was introduced
in xamarin/monodroid@a04b73b3.

*Normally* `acw-map.txt` contains three entries:

 1. The fully-qualified .NET type name
 2. The .NET type name, no assembly
 3. (2) with a lowercased namespace name, *or* the `[Register]`
    value, if provided.

For example:

	Mono.Android_Test.Library.CustomTextView, Mono.Android-Test.Library.NET;crc6456ab8145c81c4100.CustomTextView
	Mono.Android_Test.Library.CustomTextView;crc6456ab8145c81c4100.CustomTextView   
	mono.android_test.library.CustomTextView;crc6456ab8145c81c4100.CustomTextView   
	Java.InteropTests.GenericHolder`1, Java.Interop-Tests;net.dot.jni.test.tests.GenericHolder
	Java.InteropTests.GenericHolder`1;net.dot.jni.test.tests.GenericHolder          
	net.dot.jni.test.tests.GenericHolder;net.dot.jni.test.tests.GenericHolder    

However, when warning XA4214 is emitted (efbec22), there is a
"collision" on the .NET side (but *not* the Java side); (2) and (3)
are potentially *ambiguous*, so one .NET type is arbitrarily chosen.
(Collisions on the Java side result in XA4215 *errors*.)

The first line is still possible, because of assembly qualification.

Enter ``Java.InteropTests.GenericHolder`1``: this type is present in
*both* `Java.Interop-Tests.dll` *and* `Mono.Android-Tests.dll`.
dotnet/java-interop@07c73009, this was "fine" because the
`GenericHolder<T>` within `Java.Interop-Tests.dll` did not participate
in typemap generation.  Now it does, resulting in the XA4214 warning.
XA4214 *also* means that instead of three lines, it's *one* line:

	Java.InteropTests.GenericHolder`1, Mono.Android.NET-Tests;crc641855b07eca6dcc03.GenericHolder_1

Enter `<R8/>`, which parses `acw-map.txt` to create a
`proguard_project_primary.cfg` file.  `<R8/>` did it's *own* parsing
of `acw-map.txt`, parsing only *one of every three lines*, on the
assumption that *all* entries took three lines.

This breaks in the presence of XA4214, because some entries only take
one line, not three lines.  This in turn meant that
`proguard_project_primary.cfg` could *miss* types, which could mean
that `r8` would *remove* the unspecified types, resulting in
`ClassNotFoundException` at runtime:

	Java.Lang.ClassNotFoundException : crc641855b07eca6dcc03.GenericHolder_1
	----> Java.Lang.ClassNotFoundException : Didn't find class "crc641855b07eca6dcc03.GenericHolder_1" on path: DexPathList[[zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/base.apk", zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.x86_64.apk", zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.xxhdpi.apk"],nativeLibraryDirectories=[/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/lib/x86_64, /system/fake-libs64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/base.apk!/lib/x86_64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.x86_64.apk!/lib/x86_64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.xxhdpi.apk!/lib/x86_64, /system/lib64, /system/product/lib64]]
	   at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	   at Android.Runtime.JNIEnv.FindClass(String )

Update `<R8/>` to instead use `MonoAndroidHelper.LoadMapFile()`,
which reads all lines within `acw-map.txt`.  This results in a
`proguard_project_primary.cfg` file which properly contains a `-keep`
entry for XA4214-related types, such as
`crc641855b07eca6dcc03.GenericHolder_1`.


~~ Correct `java/lang/Object` mappings ~~`

Previous valiant efforts to allow `java/lang/Object` to be mapped to
"anything", not just `Java.Lang.Object, Mono.Android`, eventually
resulted in lots of unit test failures, e.g.:

`Android.RuntimeTests.XmlReaderPullParserTest.ToLocalJniHandle()`:

	System.NotSupportedException : Unable to activate instance of type Java.InteropTests.JavaLangRemappingTestObject from native handle 0x19 (key_handle 0x2408476).
	----> System.MissingMethodException : No constructor found for Java.InteropTests.JavaLangRemappingTestObject::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership)
	----> Java.Interop.JavaLocationException : Exception_WasThrown, Java.Interop.JavaLocationException
	   at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	   at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership )
	   at Android.Runtime.XmlResourceParserReader.FromNative(IntPtr , JniHandleOwnership )
	   at Android.Runtime.XmlResourceParserReader.FromJniHandle(IntPtr handle, JniHandleOwnership transfer)
	   at Android.Content.Res.Resources.GetXml(Int32 )
	   at Android.RuntimeTests.XmlReaderPullParserTest.ToLocalJniHandle()
	   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
	   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object , BindingFlags )
	--MissingMethodException
	   at Java.Interop.TypeManager.CreateProxy(Type , IntPtr , JniHandleOwnership )
	   at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )

With a partially heavy heart, we need to special-case typemap entries
by processing `Mono.Android.dll` *first*, so that it gets first dibs
at bindings for `java/lang/Object` and other types.

Update `NativeTypeMappingData` to process types from `Mono.Android`
before processing any other module.

Note that the special-casing needs to happen in `NativeTypeMappingData`
because typemaps were formerly processed in *sorted module order*, in
which the sort order is based on the *byte representation* of the
module's MVID (a GUID).  Additionally, *linking changes the MVID*,
which means module order is *effectively random*.  Consequently,
trying to special case typemap ordering anywhere else is ineffective.


~~ Other ~~

Update `JavaCompileToolTask` to log the contents of its response file.

Update LLVM-IR -related types within
`src/Xamarin.Android.Build.Tasks/Utilities` to use `TaskLoggingHelper`
for logging purposes, *not* `Action<string>`.  Update related types
to accept `TaskLoggingHelper`, so that we can more easily add
diagnostic messages to these types in the future.
simonrozsival pushed a commit that referenced this pull request Feb 23, 2024
Context: dotnet/java-interop@005c914
Context: dotnet/java-interop#1181
Context: 25d1f00

When attempting to bump to dotnet/java-interop@005c9141, multiple
unit tests would fail, e.g.

	Java.Lang.LinkageError : net.dot.jni.test.CallVirtualFromConstructorDerived
	----> System.NotSupportedException : Could not find System.Type corresponding to Java type JniTypeSignature(TypeName=net/dot/jni/test/CallVirtualFromConstructorDerived ArrayRank=0 Keyword=False) .

This happened because dotnet/java-interop@005c9141 implicitly
required that typemaps exist for `Java.Interop.JavaObject` subclasses.

Fair enough; enter xamasrin/java.interop#1181, which added support to
`Java.Interop.Tools.JavaCallableWrappers` to emit typemaps for
`Java.Interop.JavaObject` subclasses.

That caused *crashes* in `tests/Mono.Android-Tests`:

	E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x75  (index 7 in a table of size 7)
	F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75
	…
	F droid.NET_Test: runtime.cc:630]   native: #13 pc 00000000003ce865  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)

The immediate cause of the crash was a "use after free" bug within
`TypeManager.CreateInstance()` in a never-hit-before error path; the
"use after free" bug was fixed in 25d1f00.

However, the cause of the hitting a never-hit-before error path is
because `EmbeddedAssemblies::typemap_java_to_managed()` would only
map Java types to `System.Type` instances for assemblies that have
*already been loaded*.  If the assembly had not yet been loaded, then
`EmbeddedAssemblies::typemap_java_to_managed()` would return `null`,
and if the binding it couldn't find happens to be for
`java.lang.Object`, we hit the (buggy!) "Where is the Java.Lang.Object
wrapper" error condition.

Commit 25d1f00 fixes that and a great many other related issues.

What's left is `EmbeddedAssemblies::typemap_java_to_managed()`:
it should *never* return null *unless* there is no typemap at all.
Whether the target assembly has been loaded or not should be
irrelevant.

Update `EmbeddedAssemblies::typemap_java_to_managed()` so that it
will load the target assembly if necessary.

Additionally, before we figured out that we had a "use after free"
bug, all we had to go on was that *something* related to
`JNIEnv::GetObjectClass()` was involved.  Review JNI usage around
`JNIEnv::GetObjectClass()` and related invocations, and cleanup:

  * Simplify logic related to `JNIEnv::DeleteLocalRef()`.
  * Decrease scope of local variables.
  * Clear variables passed to `JNIEnv.DeleteLocalRef()`.

Co-authored-by: Jonathan Pryor <jonpryor@vt.edu>
Co-authored-by: Marek Habersack <grendel@twistedcode.net>
jonpryor pushed a commit that referenced this pull request Jul 25, 2024
Context: dotnet/maui#23694 (review)
Context: https://github.com/dotnet/maui/blob/d38ca872f68326ab623c050b0efd93c7d212e000/src/Essentials/test/DeviceTests/Tests/Preferences_Tests.cs#L305-L310
Context: dotnet/android@06bb1dc...45855b8

A .NET MAUI on-device test is crashing on API 23 emulators:

    07-23 11:35:45.837  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115] local reference table dump:
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]   Last 10 entries (of 512):
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       511: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       510: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       509: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       508: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       507: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       506: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       505: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       504: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       503: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       502: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]   Summary:
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       511 of java.lang.Class (7 unique instances)
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]         1 of android.app.SharedPreferencesImpl
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/barrier.cc:90] Check failed: count_ == 0 (count_=-1, 0=0) Attempted to destroy barrier with non zero count
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/runtime.cc:366] Runtime aborting --- recursively, so no thread-specific detail!
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/runtime.cc:366]
    --------- beginning of crash
    07-23 11:35:45.930  4252  4277 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 4277 (.NET TP Worker)
    07-23 11:35:46.003  1640  1640 I SELinux : SELinux: Loaded file_contexts contexts from /file_contexts.
    07-23 11:35:46.006  1640  1640 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    07-23 11:35:46.006  1640  1640 F DEBUG   : Build fingerprint: 'Android/sdk_google_phone_x86_64/generic_x86_64:6.0/MASTER/6695544:userdebug/test-keys'
    07-23 11:35:46.006  1640  1640 F DEBUG   : Revision: '0'
    07-23 11:35:46.006  1640  1640 F DEBUG   : ABI: 'x86_64'
    07-23 11:35:46.006  1640  1640 F DEBUG   : pid: 4252, tid: 4277, name: .NET TP Worker  >>> com.microsoft.maui.essentials.devicetests <<<
    07-23 11:35:46.006  1640  1640 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
    07-23 11:35:46.014  1640  1640 F DEBUG   : Abort message: 'art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)'
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rax 0000000000000000  rbx 00007f7dadfbf500  rcx ffffffffffffffff  rdx 0000000000000006
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rsi 00000000000010b5  rdi 000000000000109c
    07-23 11:35:46.014  1640  1640 F DEBUG   :     r8  0000000000000001  r9  0000000000000003  r10 0000000000000008  r11 0000000000000206
    07-23 11:35:46.014  1640  1640 F DEBUG   :     r12 00000000000010b5  r13 0000000000000006  r14 00007f7dc7305a40  r15 00007f7dabd70cc0
    07-23 11:35:46.014  1640  1640 F DEBUG   :     cs  0000000000000033  ss  000000000000002b
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rip 00007f7dcaa49a67  rbp 0000000000000002  rsp 00007f7dadfbc048  eflags 0000000000000206
    07-23 11:35:46.018  1640  1640 F DEBUG   :
    07-23 11:35:46.018  1640  1640 F DEBUG   : backtrace:
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #00 pc 0000000000087a67  /system/lib64/libc.so (tgkill+7)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #1 pc 0000000000085b11  /system/lib64/libc.so (pthread_kill+65)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #2 pc 000000000002e841  /system/lib64/libc.so (raise+17)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #3 pc 00000000000288fd  /system/lib64/libc.so (abort+61)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #4 pc 00000000004ffd65  /system/lib64/libart.so (art::Runtime::Abort()+341)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #5 pc 0000000000178d71  /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #6 pc 0000000000172dad  /system/lib64/libart.so (art::Barrier::~Barrier()+813)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #7 pc 000000000053de1a  /system/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+394)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #8 pc 00000000004ffea4  /system/lib64/libart.so (art::Runtime::Abort()+660)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #9 pc 0000000000178d71  /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #10 pc 00000000002f00fd  /system/lib64/libart.so (art::IndirectReferenceTable::Add(unsigned int, art::mirror::Object*)+1005)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #11 pc 00000000003ee19a  /system/lib64/libart.so (art::JNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+586)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #12 pc 00000000001abdf8  /system/lib64/libart.so (art::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, __va_list_tag*, art::Primitive::Type, art::InvokeType)+1736)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #13 pc 00000000001ae031  /system/lib64/libart.so (art::CheckJNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+33)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #14 pc 000000000004555d  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (_JNIEnv::CallObjectMethod(_jobject*, _jmethodID*, ...)+157)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #15 pc 000000000003beb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+69)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #16 pc 00000000001e8585  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #17 pc 00000000001e7020  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #18 pc 00000000001d8fb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #19 pc 00000000001d6961  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #20 pc 00000000000e5f19  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #21 pc 00000000002a96c6  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #22 pc 00000000002b202e  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #23 pc 000000000026cb84  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #24 pc 000000000027615a  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #25 pc 00000000001e8618  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #26 pc 00000000001e7066  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #27 pc 00000000001d8fb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #28 pc 00000000001d6961  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #29 pc 00000000000e5f19  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #30 pc 00000000002a96c6  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     dotnet#31 pc 00000000002c0713  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     dotnet#32 pc 0000000000084eee  /system/lib64/libc.so (__pthread_start(void*)+46)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     dotnet#33 pc 00000000000296eb  /system/lib64/libc.so (__start_thread+11)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     dotnet#34 pc 000000000001ce55  /system/lib64/libc.so (__bionic_clone+53)
    07-23 11:35:46.179  1640  1640 F DEBUG   :
    07-23 11:35:46.179  1640  1640 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_00

After some investigation, we think this was introduced in 35f41dc.

I could reproduce the issue in a simple test case:

    [Test]
    public void PutAndGetManyValues ()
    {
        for (int i = 0; i < Count; i++) {
            using var prefs = GetPreferences ();
            using var editor = prefs.Edit ();
            editor.PutString ("key" + i, "value" + i);
            editor.Apply ();
        }

        for (int i = 0; i < Count; i++) {
            using var prefs = GetPreferences ();
            Assert.AreEqual ("value" + i, prefs.GetString ("key" + i, null));
        }
    }

Which also crashed with:

    07-24 09:39:02.615  4623  4638 I NUnit   : SharedPreferencesTest
    07-24 09:39:02.615  4623  4638 I NUnit   : PutAndGetManyValues
    07-24 09:39:02.719  4623  4638 F art     : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)

I updated `TypeManager` to use a `try-finally` block, such as:

    JniObjectReference typeClass = default;
    JniObjectReference handleClass = default;
    try {
        //...
    } finally {
        JniObjectReference.Dispose (ref handleClass);
        JniObjectReference.Dispose (ref typeClass);
    }

And it appears the test case now passes on API 23 emulators. Hoping
this will also fix .NET MAUI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file submodules Pull requests that update Submodules code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants