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

Attempting to JIT compile method '(wrapper delegate-invoke) void #43

Closed
jtorvald opened this issue Sep 23, 2019 · 9 comments
Closed

Attempting to JIT compile method '(wrapper delegate-invoke) void #43

jtorvald opened this issue Sep 23, 2019 · 9 comments

Comments

@jtorvald
Copy link
Contributor

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?

@mcatanzariti
Copy link
Member

Please provide the whole callstack!

@jtorvald
Copy link
Contributor Author

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?

@mcatanzariti
Copy link
Member

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

@mcatanzariti
Copy link
Member

Also could provide your custom class and Cbor input buffer please?

@jtorvald
Copy link
Contributor Author

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

@mcatanzariti
Copy link
Member

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

@jtorvald
Copy link
Contributor Author

I will just not sure when. Quite busy at the moment. Hopefully I manage next week!

@jtorvald
Copy link
Contributor Author

Uhm can it be that you meant it the other way around? I'm using a field now and that seems to work.

@mcatanzariti
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants