Bug 57374 - Crash during conformsToProtocol used on inherited object.
Summary: Crash during conformsToProtocol used on inherited object.
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 10.10 (d15-2)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2017-06-12 13:49 UTC by nazar
Modified: 2017-07-11 07:29 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
project to reproduce the issues (96.47 KB, application/zip)
2017-06-12 13:49 UTC, nazar
Details
conforms to protocol screen on xamarin side (129.94 KB, image/png)
2017-06-12 14:22 UTC, nazar
Details
full build log (1.09 MB, text/plain)
2017-06-14 04:54 UTC, nazar
Details
system information (1.65 KB, text/plain)
2017-06-14 04:55 UTC, nazar
Details
enumerator exception from vs for mac (356.12 KB, image/png)
2017-06-14 18:35 UTC, nazar
Details
enumerator exception from xcode (454.46 KB, image/png)
2017-06-14 18:35 UTC, nazar
Details
extend interface\protocol project (108.39 KB, application/zip)
2017-06-15 11:33 UTC, nazar
Details
Structure in API, issue with overriding method (108.61 KB, application/zip)
2017-06-19 16:37 UTC, andrii
Details
Project to reproduce: Struct in API, Method override (the ugly way) (279.19 KB, application/zip)
2017-06-21 10:21 UTC, andrii
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description nazar 2017-06-12 13:49:30 UTC
Created attachment 22832 [details]
project to reproduce the issues

Hi,

I have few issues with xamarin.ios.
Please see the attached project's, I will use it as an example to explain what issues do we have.

---------------------------------
---------------------------------
What is the proper way to bind structs, or maybe some workaround...

In the attached project, we have a declaration of SCIGenericType struct in Structs.cs file, later we try to use it in ApiDefinitions.cs like bellow:

        // -(void)callMethodWithGeneric:(SCIGenericType)value;
        //[Export("callMethodWithGeneric:")]
        //void CallMethodWithGeneric(SCIGenericType value);

But it gives the build error:

        // Error MT4111: The registrar cannot build a signature for type `System.Void' in method `TestProject.ObjectBuilder.CallMethodWithGeneric`. (MT4111) (TestProjectConsumer)

What are we doing wrong and how to omit such things?

---------------------------------
---------------------------------
So we have the following workflow, we have InterfaceProtocol, Interface which implements that protocol, ObjectBuilder class to test stuff (on obj-c side). 

Then we bind that to xamarin.iOS and create InterfaceInheritor in Extras.

After that pass that object from xamarin.ios to obj-c and check if that object conforms to the above protocol like below:

    -(void)callMethodWithInterface:(id<InterfaceProtocol>)value {
        BOOL conforms = [value conformsToProtocol:@protocol(InterfaceProtocol)];
        if (conforms) {
            // do stuff
        }
    }

and it crashes right on that line, but it should pass that check...

Try to run the attached project, so you can clearly see how and where it crashes.
---------------------------------
---------------------------------
The last issue is related to binding\marhalling structs.
Due to the first problem, we can't use structs in our code, that's why we need to skip that in ApiDefinitions.cs and add extras as a partial class member. But sometimes such things are the elements of Protocols, so it would be greate to extend them as partial, which seems to be impossible. 

Am I missing something, or it is impossible to do the above?

Hope you can help us.

Thanks in advance.

Best Regards,
Nazar R
Comment 1 nazar 2017-06-12 14:22:27 UTC
Created attachment 22833 [details]
conforms to protocol screen on xamarin side
Comment 2 Vincent Dondain [MSFT] 2017-06-13 19:26:55 UTC
Hi,

Please include your full build logs, crash reports (if any) and all version information.

To get full build logs just set the log verbosity to diagnostic at the following location on Visual Studio for Mac: Preferences > Projects > Build.

Easiest way to get exact version information on Visual Studio for Mac: "Visual Studio" menu, "About Visual Studio" item, "Show Details" button.
Comment 3 nazar 2017-06-14 04:54:39 UTC
Created attachment 22875 [details]
full build log
Comment 4 nazar 2017-06-14 04:55:54 UTC
Created attachment 22876 [details]
system information
Comment 5 nazar 2017-06-14 04:58:04 UTC
Hi, Vincent

I've attached build logs and system info. There are no crash reports, it just silently crashes. Even if I attach xcode to debug.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2017-06-14 09:45:29 UTC
In your case the problem is that we don't support structs with explicit layout (with [FieldOffset (X)]) (I've opened a bug report - bug #57470 - to get a better error message for this scenario).

You can work around this by creating an intermediate struct which has the same size as the struct with the explicit layout, and use that in the bindings, and make it internal. Then you declare a public method in a partial class with the API you want to expose, and do the necessary marshalling to convert to/from the internal and public structs.

Example:

ApiDefinition.cs:

    [BaseType(typeof(NSObject))]
    interface ObjectBuilder
    {
        [Export("callMethodWithGeneric:")]
        [Internal]
        void CallMethodWithGeneric_Internal (SCIGenericType_Internal value);
    }

Structs.cs:

    public struct SCIGenericType_Internal
    {
        public SCIDataType type;
        public long data;
    }

Extra.cs (with BuildAction = Compile):

    partial class ObjectBuilder
    {
        unsafe void CallMethodWithGeneric (SCIGenericType value)
        {
            SCIGenericType_Internal ivalue = *(SCIGenericType_Internal*) &value;
            CallMethodWithGeneric_Internal (ivalue);
        }
    }
Comment 7 Rolf Bjarne Kvinge [MSFT] 2017-06-14 09:55:53 UTC
Regarding the issue with ConformsToProtocol, what happens is this:

* We assume all types (that derive from NSObject) in a binding libraries are wrapping an existing Objective-C class.
* When calling the base implementation for a method, our behaviour differs depending on whether the class in question is wrapping an existing Objective-C class, or if it's a managed subclass:
  * If it's an existing Objective-C class, we just call the method on the Objective-C instance. This call will reach the Objective-C class.
  * If it's a managed subclass, we call the method on the Objective-C *super* instance, which is the technical equivalent of the C# 'base' call. If we called the method on the Objective-C instance, we'd immediately get called back into managed code, since we're dealing with a managed subclass, which would result in a stack overflow.
* You created the InterfaceInheritor in the binding library, which means we assumed it was wrapping an Objective-C class.
* When you call ConformsToProtocol, we'd end up thinking it's wrapping an existing Objective-C class, end when trying to call the base class' ConformsToProtocol, we'd do the wrong thing and just call back into the managed code, resulting in infinite recursion and a stack overflow.

There are two possible fixes:

1. Move the declaration of InterfaceInheritor to the executable project (technically any project but the binding project).
2. Set the IsDirectBinding field to false in all of InterfaceInheritor's constructors:

    public InterfaceInheritor ()
    {
        IsDirectBinding = false;
    }
Comment 8 Rolf Bjarne Kvinge [MSFT] 2017-06-14 09:57:02 UTC
Regarding your third problem, I don't quite understand it.

However since I've explained how to use structs, maybe it's not a problem anymore?

I'm closing this now, but feel free to reopen if you have more doubts or other problems.
Comment 9 nazar 2017-06-14 18:34:31 UTC
Hi Rolf,
ComformsToProtocol is quite clear, thanks for the detailed explanation. It does work both ways. I'm going to use IsDirectBinding = false though.

Regarding SCIGenericType - you said that you don't support explicit structures. Are there any plans in the future?

The third problem, is there a way to extend (use partial) interface for bounded protocol?  I faced some issued during that.

And one more. Now I have one more problem, maybe you can help me with.

We have the collection which wraps NSArray on obj-c side. We bind it successfully. But we would like to implement IEnumerable interface on it, which requires implementation of IEnumerator.

So here is the thing. There are two ways of doing that, implementing it fully on c# side, or use something from obj-c side. Then I found your(xamarin team) implementation of it here: https://github.com/xamarin/xamarin-macios/blob/fc55e4306f79491fd269ca2495c6a859799cb1c6/src/Foundation/NSFastEnumerator.cs

When I can see you are using countByEnumeratingWithState:objects:count: so I decided to mimic your implementation (since it's internal) and I faced some issues (I'm going to attach screenshots) 
- Object reference not set to an instance of an object

stackTrace:
  at System.Runtime.InteropServices.Marshal.ReadInt64 (System.IntPtr ptr) [0x0000d] in /Library/Frameworks/Xamarin.iOS.framework/Versions/10.10.0.36/src/mono/mcs/class/corlib/System.Runtime.InteropServices/Marshal.cs:931 
  at System.Runtime.InteropServices.Marshal.ReadIntPtr (System.IntPtr ptr) [0x00014] in /Library/Frameworks/Xamarin.iOS.framework/Versions/10.10.0.36/src/mono/mcs/class/corlib/System.Runtime.InteropServices/Marshal.cs:964 
  at SciChart.iOS.Charting.Enumerator`1[T].Fetch () [0x00081] in <92e6436c41aa4888a093e7de0f7c1464>:0 
  at SciChart.iOS.Charting.Enumerator`1[T].System.Collections.IEnumerator.MoveNext () [0x00026] in <92e6436c41aa4888a093e7de0f7c1464>:0 
  at Xamarin.Examples.Demo.iOS.Views.Examples.CreateRealtimeTickingStockChartsView.InitExampleInternal () [0x000a5] in /Users/nazar/Documents/scichart_root/xamarin_trunk/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/Views/Examples/CreateRealtimeTickingStockChartsView.cs:72 
  at Xamarin.Examples.Demo.iOS.Views.Base.ExampleBaseView`1[T].InitExample () [0x00008] in <2ebc483a5f9d49d2a87afd50ad510565>:0 
  at Xamarin.Examples.Demo.iOS.Views.Base.ExampleBaseView`1[T]..ctor () [0x00008] in <2ebc483a5f9d49d2a87afd50ad510565>:0 
  at Xamarin.Examples.Demo.iOS.Views.Examples.CreateRealtimeTickingStockChartsView..ctor () [0x00059] in /Users/nazar/Documents/scichart_root/xamarin_trunk/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/Views/Examples/CreateRealtimeTickingStockChartsView.cs:34 
  at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&)
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00002] in /Library/Frameworks/Xamarin.iOS.framework/Versions/10.10.0.36/src/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:661 

but when i'm attaching xcode debugger, it shows that it's a bad access issue.

So here is the question - what is the proper way of doing that?
Comment 10 nazar 2017-06-14 18:35:12 UTC
Created attachment 22891 [details]
enumerator exception from vs for mac
Comment 11 nazar 2017-06-14 18:35:42 UTC
Created attachment 22892 [details]
enumerator exception from xcode
Comment 12 Rolf Bjarne Kvinge [MSFT] 2017-06-15 09:43:48 UTC
(In reply to nazar from comment #9)
> Hi Rolf,
> ComformsToProtocol is quite clear, thanks for the detailed explanation. It
> does work both ways. I'm going to use IsDirectBinding = false though.
> 
> Regarding SCIGenericType - you said that you don't support explicit
> structures. Are there any plans in the future?

Not really, because it's quite complex, very little demand for it (you're the first one), and a viable workaround exists.

> The third problem, is there a way to extend (use partial) interface for
> bounded protocol?  I faced some issued during that.

Can you show me in code (both the C# and the Objective-C side) what you're trying to do?

> And one more. Now I have one more problem, maybe you can help me with.
> 
> We have the collection which wraps NSArray on obj-c side. We bind it
> successfully. But we would like to implement IEnumerable interface on it,
> which requires implementation of IEnumerator.
> 
> So here is the thing. There are two ways of doing that, implementing it
> fully on c# side, or use something from obj-c side. Then I found
> your(xamarin team) implementation of it here:
> https://github.com/xamarin/xamarin-macios/blob/
> fc55e4306f79491fd269ca2495c6a859799cb1c6/src/Foundation/NSFastEnumerator.cs
> 
> When I can see you are using countByEnumeratingWithState:objects:count: so I
> decided to mimic your implementation (since it's internal) and I faced some
> issues (I'm going to attach screenshots) 
> - Object reference not set to an instance of an object

Can you attach the project with your code?
Comment 13 nazar 2017-06-15 09:48:02 UTC
Hi Rolf, thanks for the reply, I'm going to prepare small project and get back to you soon.
Comment 14 nazar 2017-06-15 11:33:24 UTC
Created attachment 22922 [details]
extend interface\protocol project
Comment 15 nazar 2017-06-15 11:35:16 UTC
Hi, Rolf, 
the last one 

> And one more. Now I have one more problem, maybe you can help me with.
> 
> We have the collection which wraps NSArray on obj-c side. We bind it
> successfully. But we would like to implement IEnumerable interface on it,
> which requires implementation of IEnumerator.
> 
> So here is the thing. There are two ways of doing that, implementing it
> fully on c# side, or use something from obj-c side. Then I found
> your(xamarin team) implementation of it here:
> https://github.com/xamarin/xamarin-macios/blob/
> fc55e4306f79491fd269ca2495c6a859799cb1c6/src/Foundation/NSFastEnumerator.cs
> 
> When I can see you are using countByEnumeratingWithState:objects:count: so I
> decided to mimic your implementation (since it's internal) and I faced some
> issues (I'm going to attach screenshots) 
> - Object reference not set to an instance of an object

> Can you attach the project with your code?

was my mistake, I've just got it working as in your repository, thanks.

As for the extending interface\protocol, please see attached projects. 

Best Regards,
Nazar R.
Comment 16 Rolf Bjarne Kvinge [MSFT] 2017-06-15 11:57:50 UTC
You're right, we currently don't support extending the interface for a protocol like you're trying to do.

This is because we also generate classes that implements those interfaces, and if you add methods to the interfaces, those classes won't compile because they won't implement your additional methods.

However, you can use extension methods to provide helper API:

   public static class IInterfaceProtocol_MyExtensions
    {
		public static string GetTestStringProperty (this IInterfaceProtocol obj)
		{
			return "something";
		}

		public static void SetTestStringProperty (this IInterfaceProtocol obj, string value)
		{
			// Do something
		}
    }

Would this work for you?
Comment 17 nazar 2017-06-15 12:51:56 UTC
I thought about extensions, and we going to use them, I just wanted to know if I'm doing something wrong.

Also since you said that it's not supported, is there any plans? I know that you can't say any dates or details but in general?
Comment 18 Rolf Bjarne Kvinge [MSFT] 2017-06-15 12:58:28 UTC
We might support extending interfaces for protocols once C# implements default interface methods [1], since then you could add such methods to the interface.

[1]: https://github.com/dotnet/csharplang/issues/52
Comment 19 nazar 2017-06-15 13:52:01 UTC
got it. Thank you very much for your help.
Comment 20 Rolf Bjarne Kvinge [MSFT] 2017-06-15 16:41:32 UTC
Great, I'll close this again then. As always, feel free to reopen if needed 🙂
Comment 21 andrii 2017-06-19 16:24:11 UTC
Hi, Rolf
We have
Comment 22 andrii 2017-06-19 16:31:51 UTC
faced another issue with structures in API.

Using structure with sequential layout only for bindings is working. 

But if we override such method in subclass and that method is called from native code - application crashes while running on simulator. 

Yet on device everything is fine.

I will attach example with the issue.

Could you please provide some solution to that issue?
Comment 23 andrii 2017-06-19 16:37:21 UTC
Created attachment 22976 [details]
Structure in API, issue with overriding method
Comment 24 Rolf Bjarne Kvinge [MSFT] 2017-06-20 10:50:20 UTC
The problem is that your TestProject.framework only contains arm64 code:

    $ file TestProject.framework/TestProject
    TestProject.framework/TestProject: Mach-O 64-bit dynamically linked shared library arm64

If I build the Xcode project for the simulator, and manually make a fat framework with both x86_64 and arm64 everything works fine:

   $ cp /Users/rolf/Library/Developer/Xcode/DerivedData/TestProject-gftslrtsteqfqfadopfplmcivpvp/Build/Products/Debug-iphonesimulator/TestProject.framework/TestProject TestProject.x86_64
   $ cp TestProject.framework/TestProject TestProject.arm64
   $ lipo -create -output TestProject.framework/TestProject TestProject.arm64 TestProject.x86_64

Unfortunately Xcode doesn't seem to provide an easy way to create a framework that works for both device and the simulator, you have to build twice and manually join them together (see also https://stackoverflow.com/questions/29634466/how-to-export-fat-cocoa-touch-framework-for-simulator-and-device).
Comment 25 andrii 2017-06-21 10:18:33 UTC
Thank you for response. It works with universal framework on simulator.

But we have yet another issue with such approach. Which is the following: we need to allow user to override the method in Xamarin which on obj-c side takes stuct as a param. 

The above approach assume that you have one private method with internal stcuct and one public with normal struct. To allow overriding native method, we need to expose private method, which brokes the whole idea of that workaround for binding explicit structs.

To sum up - we have to expose both methods: internal with internal struct which goes to the native code bindings and method in extras added for usability. Which isn't a good solution, because consumer of binding project will be forced to override method from bindings but use method from extras.

I will attach example with working but clunky way to override native method.
Do you have any suggestions how to resolve that case properly?

Thanks in advance.
Comment 26 andrii 2017-06-21 10:21:07 UTC
Created attachment 23033 [details]
Project to reproduce: Struct in API, Method override (the ugly way)
Comment 27 Rolf Bjarne Kvinge [MSFT] 2017-06-21 10:34:42 UTC
If consumers are supposed to override methods, you'll need to implement it using a single (public) struct if you want a nice API.

You can accomplish this using unsafe code to poke into the struct values instead of using an explicit struct:

	[StructLayout (LayoutKind.Sequential)]
	public struct SCIGenericType
	{
		public SCIDataType type;
		ulong data;

		public unsafe sbyte charData {
			get {
				fixed (ulong* ptr = &data) {
					return *(sbyte *) ptr;
				}
			}
			set {
				fixed (ulong* ptr = &data) {
					*(sbyte *) ptr = value;
				}
			}
		}

		public unsafe short int16Data {
			get {
				fixed (ulong* ptr = &data) {
					return *(short *) ptr;
				}
			}
			set {
				fixed (ulong* ptr = &data) {
					*(short *) ptr = value;
				}
			}
		}

		// ...
	}
Comment 28 nazar 2017-06-24 14:33:55 UTC
Hi Rolf,

the above way could be as an ok workaround until xamarin will support explicit structs natively. Thank you.

but I still have a question, which is related unsafe bindings.

There are snippets of code, which are unsafe, e.g. 

-(instancetype _Nonnull)initWithGradientStops:(float * _Nonnull)stops colors:(uint * _Nonnull)colors count:(int)count direction:(SCILinearGradientDirection)direction;

and obj sharpie binds it as following

unsafe IntPtr Constructor(float* stops, uint* colors, int count, SCILinearGradientDirection direction);

but using that I've got an error: Do not know how to make a signature for System.Single* in parameter 'stops' from ...

it's not the only place, and it would be good to bind such code somehow (properly)

could you suggest something? 

Thank you very much for your help.
Comment 29 Rolf Bjarne Kvinge [MSFT] 2017-06-26 12:25:56 UTC
You can bind those as IntPtr:

    unsafe IntPtr Constructor (IntPtr stopsptr, IntPtr colorsptr, int count, SCILinearGradientDirection direction);
    {
        float stops = *(float *) stopsptr;
        uint colors = *(uint *) colorsptr;

        // ...

        *(uint *) colorsptr = colors;
        *(float *) stopsptr = stops;
    }

This is something it should be quite easy to fix though. Does this happen with any other type than float* and uint*?
Comment 30 nazar 2017-06-26 12:48:30 UTC
ok, does that code can be directly bounded? or it should go into extras?
Comment 31 Rolf Bjarne Kvinge [MSFT] 2017-06-26 12:50:16 UTC
If users won't need to override that method, you can put it in extras.

Otherwise it will have to be a directly bound method, and overriding methods would have to use unsafe code like above.
Comment 32 nazar 2017-06-26 12:53:36 UTC
>> Otherwise it will have to be a directly bound method, and overriding methods would have to use unsafe code like above.

does that mean that we can use that code in ObjCBindingAPIDefinition type of files?

>> unsafe IntPtr Constructor (IntPtr stopsptr, IntPtr colorsptr, int count, SCILinearGradientDirection direction);

without a body? or it should contain the above transformation?

    {
        float stops = *(float *) stopsptr;
        uint colors = *(uint *) colorsptr;

        // ...

        *(uint *) colorsptr = colors;
        *(float *) stopsptr = stops;
    }

where does the above transformation goes?
Comment 33 Rolf Bjarne Kvinge [MSFT] 2017-06-26 13:09:17 UTC
Actually never mind, I didn't realize it's a constructor so it can't be overridden. Also it seems the float and uint pointers are arrays (according to the documentation).

So I think the best would be to do something like this:

ApiDefinition.cs:

    [BaseType (typeof (Y))]
    interface X {
        [Internal]
        [Export ("initWithGradientStops:colors:count:direction:")]
        IntPtr InitWithGradientStops (IntPtr stops, IntPtr colors, int count, SCILinearGradientDirection direction);
    }

StructsAndEnums.cs:

    partial class X {
        public X (float[] stops, uint[] colors, SCILinearGradientDirection direction)
        {
            if (stops == null) throw new ArgumentNullException ();
            if (colors == null) throw new ArgumentNullException ();
            if (stops.Length != colors.Length) throw new ArgumentOutOfRangeException ();
            if (stops.Length == 0) throw new ArgumentOutOfRangeException ();

            fixed (float* stopsPtr = &stops [0])
                fixed (uint* colorsPtr = &colors [0])
                    InitializeHandle (InitWithGradientStops (stopsPtr, colorsPtr, stops.Length, direction);
        }
    }
Comment 34 nazar 2017-06-27 09:43:39 UTC
hi Rofl, thanks, that actually might work, thank you

meanwhile, I was working on another part of the binding, and realized, that there is no NSMapTable in xamarin, is that right? 

If it is - it there a known workaround?
Comment 35 Rolf Bjarne Kvinge [MSFT] 2017-06-27 12:17:01 UTC
No, NSMapTable is one of the very few types we haven't bound, so it's not in Xamarin yet.

How is this type used? Can you link to documentation? That would make it possible for me to come up with better alternatives.
Comment 36 nazar 2017-06-27 13:28:42 UTC
there is no documentation yet, but i can share the method declaration 

+ (nonnull NSMapTable<id<SCISuspendableProtocol>, NSNumber*> *)suspendedInstances;

which supposed to be bounded like below

        //// +(NSMapTable<id<SCISuspendableProtocol>,NSNumber *> * _Nonnull)suspendedInstances;
        //[Static]
        //[Export("suspendedInstances")]
        //NSMapTable<ISCISuspendableProtocol, NSNumber> SuspendedInstances { get; }
Comment 37 nazar 2017-06-27 13:29:41 UTC
also since you are here, maybe you have any contacts with android team, there is an issue which is quite critical for us, but there is no any response there...

https://bugzilla.xamarin.com/show_bug.cgi?id=56436
Comment 38 Rolf Bjarne Kvinge [MSFT] 2017-06-28 05:55:54 UTC
If you control the native side, I think it would be easiest to expose it as a dictionary (by using [NSMapTable dictionaryRepresentation], something like this:

ApiDefinition.cs:

    [Internal]
    [Export ("suspendedInstances")]
    IntPtr SuspendedInstances { get; }

StructsAndEnums.cs:

    public NSDictionary<ISCISuspendableProtocol, NSNumber> SuspendedInstancesDictionary {
        get {
            var dict = IntPtr_objc_msgSend (_SuspendedInstances, Selector.GetHandle ("dictionaryRepresentation");
            return Runtime.GetNSObject<NSDictionary<ISCISuspendableProtocol, NSNumber>> (dict, false));
        }
    }

    [DllImport ("/usr/lib/libobjc.dylib", EntryPoint="objc_msgSend")]
    extern static IntPtr IntPtr_objc_msgSend (IntPtr receiver, IntPtr selector);

I've also asked the android team about your other bug.
Comment 39 nazar 2017-06-29 08:02:52 UTC
hi, Rolf, thank you for the response and for contacting Android team, he has already confirmed that bug. Thanks a lot.

so regarding NSMapTable, we control native side, but we can't replace 

>> + (nonnull NSMapTable<id<SCISuspendableProtocol>, NSNumber*> *)suspendedInstances

with NSDictionary, because of the internal implementation of its containing class.

Or the above method doesn't require rewriting that? I mean, there should be a dictionaryRepresentation prop on the native side, which brings those instances as dictionaries, right?
Comment 40 Rolf Bjarne Kvinge [MSFT] 2017-07-03 10:27:45 UTC
Yes, exactly, my code calls dictionaryRepresentation on the native side.
Comment 41 nazar 2017-07-11 07:21:09 UTC
Hi, Rolf,

thank you for all your help, we decided not to bind that because it's not that important, also because NSMapTable should be properly set up do get proper dicionaryRepresentation. So we decided to leave it until it will be bound natively.

Also, I'd like to thank you for your responses, you've helped us a lot and we do really appreciate that.

I think you can close this ticket, if we have any other question, I will reopen it, or create a new one. Thank you very much.

Best regards,
Nazar R.
Comment 42 Rolf Bjarne Kvinge [MSFT] 2017-07-11 07:29:36 UTC
Great!