5

I'm working on a build system for a fairly large MonoTouch application which is using a lot of cross-platform components. As a result, we often run into a situation where one of those cross-platform components does something that cannot be aot compiled. Should that something actually get executed, the device build will crash. At that point, we have to track down where the crash happened, find the offending method, and hack it up so that it won't try to JIT in the MonoTouch build.

My question is, is there a way to detect these things during the build process? At first, we had a regex that tried to detect generic virtual methods, but there are also issues with certain types of LINQ and lambdas that will try to JIT as well, and I'd rather not try to write my own parser to detect them all. I've tried using monodis AssemblyName.dll, and it will give me a lot of missing method errors, but most of them seem to be innocuous - and even if they weren't, it doesn't tell me where the references to said method are so that I can see what needs to be done. On top of that, sometimes it will crash with Abort trap: 6 or Bus error: 10 before the end of the assembly, which is quite unhelpful. Is there a better way I can detect attempts to JIT in my build process?

David Merriman
  • 6,056
  • 1
  • 18
  • 18

2 Answers2

1

My question is, is there a way to detect these things during the build process?

No. Using the JIT (or more accurately the exception that it's trying to use the JIT) is a runtime fallback when something is not found inside the native executable.

It's not impossible (nor easy) to detect (some/most) conditions leading to the exception using your own tool (it could even be a Gendarme rule). However this is a moving target since we're fixing reported issues so you'll have to update your tooling with each new version (or risk spending time fixing things that are not issues anymore).

What would be really helpful (with or without your own tool) is to report such issues so they can be tracked and become part of Xamarin's test suite.

I've tried using monodis AssemblyName.dll

monodis requires to have access to all assembly references, otherwise it won't work (and can crash).

poupou
  • 43,413
  • 6
  • 77
  • 174
  • 1
    About this moving target... We were under the impression that some things like generic virtual methods were not supported because they cannot be. Is that something that could change? We're okay reporting things that should work but don't; the trouble is the universe of things that should never work. – David Merriman Mar 07 '12 at 21:17
  • Personally I don't know (except compiling every possibilities) how to solve it (but other people are looking at the issues. So in doubt you better fill a bug report - worse case it will be closed as a duplicate of an existing one. – poupou Mar 07 '12 at 22:21
0

On "detect" part: when you figure out what construct causes problems create FxCop custom rule(s) that detects it and run it on normal assemblies. This way you will not need to write your own parser.

Links: FxCop - http://msdn.microsoft.com/en-us/library/bb429476%28v=VS.80%29.aspx Custom rules for FxCop how-to: http://www.codeproject.com/Articles/30666/7-Steps-to-Write-Your-Own-Custom-Rule-using-FXCOP

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • If I'm not mistaken, FxCop is a Windows-only tool, and therefore not available to us. Even with some similar tools in Mono, the issue is more that there are many constructs that can cause this to happen, and we do not yet know what all of them are, so we could still miss some using an FxCop-like approach. – David Merriman Mar 07 '12 at 19:06
  • Yes to my knowledge. Should have figured out that monotouch=="your source platform is not Windows". (Also problem of "how to detect if a compiler will work successfully on particular sources" is in general hard one (http://en.wikipedia.org/wiki/Halting_problem) :), so finding issues and then detecting particular ones in sources may be safer approach). – Alexei Levenkov Mar 07 '12 at 19:19
  • This may be easier than the halting problem, in that an attempt to call a method that was not compiled ahead of time should (in theory) be differentiable from one that was, at least in the sense that there will be code for the latter and none for the former. It's just a matter of doing such a comparison. Ideally, there'd be some kind of red flag we could find in the generated IL code. – David Merriman Mar 07 '12 at 19:27