Native crashes in MonoTouch

If you use MonoTouch a bit, you will once in a while run into native crashes. In a perfect world you'd never see such a horrible thing, but unfortunately the world isn't perfect, and in real life there are several ways you can end up crashing your app. Usual debugging techniques with MonoDevelop will not work, but with some ingenuity you can figure out what's going on. And you will catch a glimpse of how the world is for those poor guys who can't develop in C#!

Now, how do you find out what happened? You need as much information as possible, and information related to a native crash is twofold:

• Crash report.
• Console output.

Where you can find each differs depends on whether you're running in the iOS simulator or on an iOS device.

You're running in the iOS simulator.

In this case, the console is the system console on your Mac. You can find the Console application in Applications -> Utilities -> Console. This is how it looks like:

Now let's see what happens if you crash in the simulator. You will get this dialog:

and if you click the Report button, you'll see the crash report:

The same crash report is also available in the Console, in case you dismissed the dialog:

You're running on an iOS device.

In this case, you want Xcode's Organizer. Open Xcode, and go to the Window -> Organizer menu entry.

Here you will find crash reports under the Device Logs node, and the obviously the console output will be under the Console node.

Now what?

Some times the information you found tells you exactly what happened.

This is the case for an unhandled exception, in which case you'll see something like this in the console:

13/04/12 4:28:54.101 PM CrashReporting: 

Unhandled Exception: System.Exception: Unhandled I am!

  at CrashReporting.AppDelegate.UnhandledException () [0x00000] in /Users/rolf/Projects/CrashReporting/AppDelegate.cs:27 

  at MonoTouch.Dialog.StringElement.Selected (MonoTouch.Dialog.DialogViewController dvc, MonoTouch.UIKit.UITableView tableView, MonoTouch.Foundation.NSIndexPath indexPath) [0x0000b] in /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/Elements.cs:691 

  at MonoTouch.Dialog.DialogViewController.Selected (MonoTouch.Foundation.NSIndexPath indexPath) [0x00029] in /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/DialogViewController.cs:518 

  at MonoTouch.Dialog.DialogViewController+Source.RowSelected (MonoTouch.UIKit.UITableView tableView, MonoTouch.Foundation.NSIndexPath indexPath) [0x00019] in  /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/DialogViewController.cs:364 

  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)

  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0004c] in /mono/ios/monotouch/src/UIKit/UIApplication.cs:38 

  at CrashReporting.Application.Main (System.String[] args) [0x00000] in /Users/rolf/Projects/CrashReporting/Main.cs:17 

in this case it's pretty obvious what happened. But this isn't often the case, usually the information is at best unfamiliar unless you already have experience debugging native crashes (and in some cases the crash happens way after the underlying cause, and any relevant information is long lost. When this happens you'll have to resort to more creative debugging techniques).

I will write more blog posts describing some of the most common reasons for native crashes later, but in the mean time you have a few options to get help:

• The monotouch mailing list. There is also a forum interface to the mailing lists.
• File a bug.
  
• Contact Xamarin support.
  

In all cases be sure to include all information you're able to gather, have in mind that even though the console output and crash reports may be greek to you, it may provide valuable information to somebody else.

Hackweeek

A couple of weeks ago we had another hackweek at Novell, and I continued working on getting vbnc to use cecil, as I did last time. With a big difference: I finished.

Yep, vbnc now uses Cecil to emit assemblies, the System.Reflection.Emit API is not used anymore. This makes it possible to fix a few long standing bugs, but most importantly (to me at least, the bugs are quite corner-case), a lot of unnecessary code has been deleted (~10k fewer lines of code in the compiler).

Another advantage is that it's now trivial to add support for compiling to different runtime versions - vbnc won't ever suffer from multiple personalities like the mono's C# compiler does: mcs/gmcs/smcs/dmcs...

Performance is still somewhat lower (bootstrapping the compiler itself is ~20% slower), but I haven't even looked at why (almost 3 years of working on a branch with fairly big changes has probably introduced some non-optimal code), so this is likely to change. Speed is also helped by using the new cecil/light which jbevain released recently.

And since I was done a day early and wanted to have a break from what I've been doing for the last 3 years with vbnc, I implemented the first VB 9 feature: ternary ifs!

ASX playlists

If you tried watching Nasa TV in my last post with Silverlight, you'd find that it wouldn't work. And once again the problem is with the ASX file - to be more specific, the exact same problem I had to find a quick fix for last week for Moonlight.

The ASX file I linked to links to another ASX file. This second ASX file has a copyright symbol in it (©), and it stores it in the CP1252 code page (i.e. the binary value 0xA9 - this is an illegal value in utf8). Now it seems like Silverlight expects the file to be in utf8 [1], and it errors out if it isn't [2].

Unfortunately I can't link to the real mms link, Yahoo seems to uses some sort of authentication ensuring that you got the link from the ASX playlist.

I notified Yahoo using their contact form about this, asking them to fix their ASX output, now let's see what happens...

[1] When there are no byte-order markers at least
[2] Windows Media Player plays the ASX file just fine.

Nasa TV

Interested by the NASA's crash landing on the moon, I wanted to watch the event live on my Linux machine. NASA has a few live TV channels, but none seemed to work on Linux. Until I discovered that they use ASX files to view the channels in Windows Media Player - turns out Silverlight (and by consequence Moonlight) also support ASX files. It was just a matter of creating a simple silverlight application referencing the ASX links. And that's what I did!

The bad thing is that our ASX support was a bit broken [1], and I had to fix it. This means that the currently released beta is not able to view the streams, you need to download brand new xpis from here: x86 / x64 (fair warning: these xpis are not tested at all, download at your own risk). Download, restart firefox and you should be able to watch the event live here.

(video is scaled 200%, quality is kinda bad, but that's how it's transmitted from NASA)

[1] IMHO ASX files are broken by themselves - they look like xml files but aren't (they don't escape special characters that xml files have to), and they're encoded in the current encoding of the machine generating the ASX file, and in order to correctly parse the file you have to know which encoding that is (the file itself doesn't know).

Git & make

One of the most annoying issues with git (which is actually a side-product of the fact that it's very easy to create/administer branches), is that switching branches will cause a lot of recompiles.

ccache helps some, but the real life-saver here is a script which doesn't come bundled with your installed git, but which you'll have to download the source code to get: git-new-workdir. It clones your repository to a different directory, with some symlink magic so that everything is shared except the index. It's the git equivalent a checkout of a svn repository to different directories, except that anything you do in any of the directories is available in all directories.

Git & Whitespace

Recently I've been slowly transitioning from svn to git, though one of the mildly annoying differences is that git likes to colorize trailing whitespace in diffs with a very distracting color:



First try at fixing it: a tiny script to fix the file before committing.

Oops, that introduced a huge number of changes and would mess up history quite a bit, not the way to go.

So I added this to my ~/.gitconfig:

[core]
 whitespace = -trailing-space

and now I can see the important changes in the diffs again.

Cecil Reloaded

For our hack week here at Novell I continued hacking on making vbnc work with Cecil, and yesterday I reached the point where vbnc is able to compile itself using only Cecil (in my previous post I also said vbnc was able to bootstrap, but back then vbnc was still using SRE to do all the hard work, and Cecil just to write the final assembly to disk).

The initial performance problems are mostly gone, it's still not quite as fast as before, but there are also quite a few low-hanging fruit yet in that area. The first successful bootstrap yesterday took 40 seconds (compared to 12 seconds for the normal vbnc), and after a few optimizations I'm now down at 24 seconds. Almost all of that time was gained by allocating less strings, the first non-optimized version allocated ~1.4 GB of strings, and it's now down to 119 MB.

I'm also using a delay-loading mechanism to load data from referenced assemblies on-demand, this is not that visible when you compile a lot of code in one go, but it sure make a difference when compiling thousands of 15-20 line tests one by one.

I'm pretty confident I can get compilation time down to the 12 seconds I had before, especially given that Cecil hasn't been much optimized [1] (not actually used by compilers) before, while Mono's SRE implementation is known to be quite fast.

As a sidenote the actual amount of code in the compiler has decreased, from ~75k lines with the normal vbnc to ~68k for the cecil version.

[1] Sébastien Pouliot corrected me, cecil is used by some know compilers, and probably some unknown too. Some parts of Cecil has also been optimized already.