Repository navigation
Test failure in TestBundleIntegerArrayList2 when the shared runtime is enabled #4596
Description
Steps to Reproduce
- Build commercial xamarin-android in the debug configuration
- Build and run the runtime suite:
bin/Debug/bin/xabuild /restore src/Mono.Android/Test/Mono.Android-Tests.csproj /p:AndroidUseSharedRuntime=True /t:AcquireAndroidTarget,Install,CheckAndRecordApkSizes,RunTestApks
- TestBundleIntegerArrayList2 fails:
04-21 14:52:22.677 18253 18271 E NUnitLite: Test 'Xamarin.Android.RuntimeTests.BundleTest.TestBundleIntegerArrayList2' failed: System.MemberAccessException : Cannot create an instance of Android.Runtime.JavaList`1[T] because Type.ContainsGenericParameters is true.
04-21 14:52:22.677 18253 18271 E NUnitLite: at System.Reflection.RuntimeConstructorInfo.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in <a71bc0650544428ea4f1cb0a371f7a80>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at System.Reflection.RuntimeConstructorInfo.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <a71bc0650544428ea4f1cb0a371f7a80>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] in <a71bc0650544428ea4f1cb0a371f7a80>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Java.Interop.TypeManager.CreateProxy (System.Type type, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x0001b] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) [0x00111] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Java.Lang.Object.GetObject (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type type) [0x00023] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Java.Lang.Object._GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00017] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Java.Lang.Object.GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00000] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Android.OS.Bundle.Get (System.String key) [0x0003d] in <1d456e9a51254e87a1ca3e16f71731f5>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at Xamarin.Android.RuntimeTests.BundleTest.TestBundleIntegerArrayList2 () [0x00025] in <5daacb16ac9f4a9dab0d94f83afb3ab7>:0
04-21 14:52:22.677 18253 18271 E NUnitLite: at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
04-21 14:52:22.677 18253 18271 E NUnitLite: at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <a71bc0650544428ea4f1cb0a371f7a80>:0
I tried dropping the test source into a regular dummy app and did not see the same crash however...
Activity
pjcollins commentedon Apr 24, 2020
I've got a better reproduction for this and it's also affecting d16-6. You can hit this by installing and running https://github.com/xamarin/monodroid-samples/tree/master/android5.0/DrawableTinting on device in Debug mode.
The crash happens here - https://github.com/xamarin/monodroid-samples/blob/master/android5.0/DrawableTinting/DrawableTinting/DrawableTintingFragment.cs#L118
I've linked logcat output for the latest d16-6 results runtime test failure and the DrawableTinting sample crash.
jonpryor commentedon Apr 27, 2020
Related:
[typemaps] Don't create `System.Type` instance for generic types
[monodroid] Return first entry in binary_search
[monodroid] Return first entry in binary_search
brendanzagaeski commentedon May 6, 2020
Partly just for my own future reference, I'll record that setting
$(AndroidLinkMode)=Nonein the Release configuration in the DrawableTinting sample produces the sameMemberAccessException, so, as expected given the nature of the underlying issue, this issue can in theory also affect apps built in the Release configuration.grendello commentedon May 6, 2020
The
Releasebuilds don't use strings with the managed types. Each Java type name is associated with exactly one managed type using MVID (managed assembly's module UUID) and the type token id. The same is true in reverse - aMVID:TOKEN_IDpair matches exactly one Java type name (we have code in place which handles Java type name duplicates by associating variousMVID:TOKEN_IDpairs to the same type name). Therefore, binary search never has to deal with duplicates in the array and always the first type found when generating the type map is placed in the lookup array. None of the repros here triggered the isue in Release mode.[WIP] Handle duplicate java to managed type maps properly
[typemaps] Handle duplicate java to managed type maps properly
4 remaining items
[typemaps] Handle Java to managed type maps properly
[typemaps] Handle Java to managed type maps properly (#4656)
[typemaps] Handle Java to managed type maps properly (#4656)
[typemaps] Handle Java to managed type maps properly (#4656)
pjcollins commentedon May 11, 2020
@grendello I'm seeing a new startup crash with the DrawableTinting test case with this patch applied to d16-6: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
I'm worried about other potential fallout/risk on d16-6 with changes coming this late (unfortunately in part due to detection of this issue coming late in the cycle). Do we have a sane way to revert to d16-5 behavior here for the shorter time frame and look to address this more properly in d16-7 or d16-8? I understand this would carry a performance hit but I think it would be preferable to limit the scope of change in d16-6 at this point if possible.
[typemaps] Fix a log statement which may lead to segfault when used
[typemaps] Fix a log statement which may lead to segfault when used (#…
[typemaps] Fix a log statement which may lead to segfault when used (#…
[typemaps] Fix a log statement which may lead to segfault when used (#…
brendanzagaeski commentedon May 15, 2020
Release status update
A Preview version of Xamarin.Android has now been published on macOS that includes the fix for this item.
The fix is not yet available on Windows. I will update this item again when a version with the fix is available on Windows.
Fix included in Xamarin.Android 10.3.1.0.
Fix included on macOS in Visual Studio 2019 for Mac version 8.6 Preview 6. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.
Fix not yet available on Windows.
brendanzagaeski commentedon May 20, 2020
Release status update
A new Release version of Xamarin.Android has now been published on both Windows and macOS that includes the fix for this item.
Fix included in Xamarin.Android 10.3.1.0.
Fix included on Windows in Visual Studio 2019 version 16.6. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.
Fix included on macOS in Visual Studio 2019 for Mac version 8.6. To get the new version that includes the fix, check for the latest updates on the Stable updater channel.