[ | Date | | | 2012-02-10 21:50 -0500 | ] |
[ | Mod. | | | 2012-02-13 21:44 -0500 | ] |
Seems like this iPhone is all out of trampolines:
(Filename: [...]/iPhonePlayer-armv7/UnityEngineDebug.cpp Line: 34)
Ran out of trampolines of type 2 in '[...]/mscorlib.dll' (128)
This problem apparently stems from a combination of some or all of the following real or imaginary causes, brought together by attempting to program iOS devices in C#:
iOS may forbid memory pages that are both writable and executable (this sounds like the sensible thing to do in any case, provided that there is still a way to JIT-compile);
Apple may forbid JIT compilation, perhaps as a consequence of forbidding applications from running code that was not present when the build was submitted to them for review;
the mono runtime normally JIT-compiles .net bytecode;
mono has an option to AOT-compile code to a form that the following invocation of mono will generally be able to run JIT-less;
some constructs are difficult or impossible to completely resolve at compile-time: these use up pre-allocated trampoline slots, of which there are three types (in the standard JIT mode of execution, it is normal for many thousands of trampolines to be generated, and I assume they are then allocated as needed).
Therefore, if one is unlucky and their program runs in a way that it requires more trampolines than were statically allocated, a crash ensues. It is not 100% clear from the documentation what constructs causes which kind of trampoline to get used, but when running tethered on the iOS device, the error printed to the log when running out of trampolines allows one to trace the source code location that caused it, so it should be vaguely possible to investigate.
Note for the curious: the band-aid solution in this case was to... request more trampolines! To get four kilo-trampolines of type two:
mono --aot=nimt-trampolines=4096
IMT trampolines, type 2, are apparently comsumed when "making heavy use of interfaces", and 128 of them are allocated by default; RGCTX trampolines, type 1, are for "recursive generics", there are 1024 of those by default (option nrgctx-trampolines
); and "method trampolines" (I assume this means generic methods), type 0, of which there are normally 1024, are allocated with option ntrampolines
.
Another issue, which one is likely to discover at the same time as the previous one, is that of "Attempting to JIT compile method [...] while running with --aot-only" error messages. This is caused, I think, by calling methods that mono was unable to AOT-compile. More recent versions of mono accept a print-skipped
option to display the names of methods that could not be compiled.
Quick links: