Skip to content

Test failure in TestBundleIntegerArrayList2 when the shared runtime is enabled #4596

Closed
#4673
#4656
Closed
Test failure in TestBundleIntegerArrayList2 when the shared runtime is enabled#4596
#4673
#4656
Assignees
grendello
Labels
Area: App RuntimeIssues in `libmonodroid.so`.regression
Milestone
Published: 10.3 (d16-6)

Description

@pjcollins
pjcollins
opened on Apr 21, 2020

Steps to Reproduce

  1. Build commercial xamarin-android in the debug configuration
  2. 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
  1. 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

  1. pjcollins
    added
    Area: App RuntimeIssues in `libmonodroid.so`.
    on Apr 21, 2020
  2. pjcollins
    assigned
    grendello
    on Apr 21, 2020
  3. VincentDondain
    added this to the d16-7 milestone on Apr 21, 2020
  4. pjcollins
    modified the milestones: d16-7, d16-6 on Apr 24, 2020
  5. pjcollins
    added
    regression
    on Apr 24, 2020

  6. pjcollins commented on Apr 24, 2020

    @pjcollins
    pjcollins
    on Apr 24, 2020
    MemberAuthor

    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.

  7. jonpryor commented on Apr 27, 2020

    @jonpryor
    jonpryor
    on Apr 27, 2020
    Contributor

    Related:

  8. grendello
    added a commit that references this issue on Apr 30, 2020

    [typemaps] Don't create `System.Type` instance for generic types

    a8309f7
  9. jonpryor
    added 2 commits that reference this issue on May 1, 2020

    [monodroid] Return first entry in binary_search

    7a317f8

    [monodroid] Return first entry in binary_search

    5016dc4

  10. brendanzagaeski commented on May 6, 2020

    @brendanzagaeski
    brendanzagaeski
    on May 6, 2020
    Contributor

    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.

    Partly just for my own future reference, I'll record that setting $(AndroidLinkMode)=None in the Release configuration in the DrawableTinting sample produces the same MemberAccessException, so, as expected given the nature of the underlying issue, this issue can in theory also affect apps built in the Release configuration.

  11. grendello commented on May 6, 2020

    @grendello
    grendello
    on May 6, 2020
    Contributor

    The Release builds 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 - a MVID:TOKEN_ID pair matches exactly one Java type name (we have code in place which handles Java type name duplicates by associating various MVID:TOKEN_ID pairs 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.

  12. grendello
    added 2 commits that reference this issue on May 6, 2020

    [WIP] Handle duplicate java to managed type maps properly

    b00d4bc

    [typemaps] Handle duplicate java to managed type maps properly

    db35006

  13. 4 remaining items

  14. grendello
    added a commit that references this issue on May 8, 2020

    [typemaps] Handle Java to managed type maps properly

    f56d333
  15. jonpryor
    closed this as completedin #4656on May 8, 2020
  16. jonpryor
    added 3 commits that reference this issue on May 8, 2020

    [typemaps] Handle Java to managed type maps properly (#4656)

    a017561

    [typemaps] Handle Java to managed type maps properly (#4656)

    44f1532

    [typemaps] Handle Java to managed type maps properly (#4656)

    b426f96

  17. pjcollins commented on May 11, 2020

    @pjcollins
    pjcollins
    on May 11, 2020
    MemberAuthor

    @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.

  18. grendello
    added a commit that references this issue on May 11, 2020

    [typemaps] Fix a log statement which may lead to segfault when used

    e24a4ab
  19. jonpryor
    added 3 commits that reference this issue on May 11, 2020

    [typemaps] Fix a log statement which may lead to segfault when used (#…

    93f9d66

    [typemaps] Fix a log statement which may lead to segfault when used (#…

    be51423

    [typemaps] Fix a log statement which may lead to segfault when used (#…

    5443251

  20. brendanzagaeski commented on May 15, 2020

    @brendanzagaeski
    brendanzagaeski
    on May 15, 2020
    Contributor

    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.

  21. brendanzagaeski commented on May 20, 2020

    @brendanzagaeski
    brendanzagaeski
    on May 20, 2020
    Contributor

    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.

  22. brendanzagaeski
    modified the milestones: d16-6, Published: 10.3 (d16-6) on May 20, 2020
  23. ghost locked as resolved and limited conversation to collaborators on Jun 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Area: App RuntimeIssues in `libmonodroid.so`.regression

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions