Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 1583 [details]
Project containing three situations where MonoTouch attempts to JIT at runtime
Attached is a project which demonstrates 3 different situations we've run into where cross-platform code is not AOT compiled, and crashes at runtime. They can be observed by defining the symbols JIT_FAIL_1, JIT_FAIL_2, and JIT_FAIL_3 respectively. All still try to JIT at runtime as of MonoTouch 5.2.10. I have not yet tried any of the alphas.
The first situation is an override of a virtual generic method. I believe this is expected to fail, since it is probably impossible to compile such a method AOT. However, for projects that share code with environments that allow JIT compilation, it would be nice if MonoTouch could detect this particular pattern at compile time and fail the build.
The other two situations involve generic types, IEnumerable, and extension methods, and it's possible that they could be detected and compiled correctly AOT, but right now that is not happening. If possible, they should be compiled AOT. If not, it would be preferable to have a compile time error instead of finding it at run time - especially because these two situations are harder to detect with the static analysis tools we're using to mitigate the issue right now.
Also, here is the StackOverflow question that prompted this bug report, for completeness:
I can confirm the three cases still fails with the latest alpha release.
The first one for being a generic virtual method.
The other two looks related to the use of KeyValuePair<TKey,TValue> which is a value-type and often, like the test case, nested a few times. That makes them harder to detect (or workaround).
I'll include the tests in our test suite (so we can test new ideas and version against it) and we'll update this bug report whenever one is fixed. Thanks.
The three test cases we added for this bug now works fine in 6.3.x.
6.3.x beta releases have much improved to avoid this situation (the EngineExecutionException). You might want to try this, or similar code, again and report any remaining issues (with a test case).