Attempting to JIT compile method '(wrapper delegate-invoke) void
Closed this issue · 9 comments
On a real iOS with Xamarin it goes wrong on a DateTime field.
Attempting to JIT compile method '(wrapper delegate-invoke) void :invoke_callvirt_void_ConversationMessage_DateTime ConversationMessage,System.DateTime)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information.
Do you have any idea how I can fix this? Writing a converter for DateTime didn't work. Should I write a converter for the whole class?
Please provide the whole callstack!
If I step through it, it's:
DateTimeConverter.cs:24
return DateTimeOffset.FromUnixTimeSeconds(unixTime).DateTime;
MemberConverter.cs:51
_memberSetter((T)obj, _memberConverter.Read(ref reader)); <-- HERE
Probably something with:
private readonly Action<T, TM> _memberSetter;
It has to do with the limitations of Xamarin.iOS described in the URL above and probably has to do with the Generic T but not sure what and how to go around it. Is it possible to have a converter without using this generic code?
Sorry,
It's not clear enough.
MemberConverter.cs:51
_memberSetter((T)obj, _memberConverter.Read(ref reader));
is called for every type of property, integers, floats, strings, objects, collections etc. Not only DateTime.
If it fails for DateTime, it should fail for any other type. Is it the case?
Does the Xamarin JIT problem trigger any kind of exception?
If it's the case it would be helpful to get the full callstack of this exception to give me more hints about the problem.
Thank you
Also could provide your custom class and Cbor input buffer please?
@mcatanzariti the problem is that there is no full callstack because it does not give me an exception. It probably gets swallowed somehow. It appears as a debug message in the logs, no exception.
I changed the data type to a long and that works. It's weird because other scalar types and my own classes work. When I make it a long instead of DateTime it works.
Reading the limitations does not ring a bell?
I will try to give some clarity about this later this week, hopefully with custom class and cbor buffer.
Hi,
When you have time, could you provide a custom class?
I have an hypothesis, if you use a field instead of a property, the field accessor is generated by compiling an expression tree, which trigger the JIT. So it won't be compatible with Xamarin AOT...
I will just not sure when. Quite busy at the moment. Hopefully I manage next week!
Uhm can it be that you meant it the other way around? I'm using a field now and that seems to work.
Hum I cannot explain it because the field getter/setter are generated by invoking the JIT whereas the property getter/setter already exist and are invoked by reflection