OK, that was nasty to find. I've been plagued on and off by a crash bug that I only seem to see on the iPad and it's never been very reproducible. Today I was putting textures in the background of the iPad screens and found a reproducible crash. Hooray! Except as soon as I put a breakpoint in the crash would go away so there's some sort of race condition/multithreading going on. Mumble grumble.
The breakpoint was everyone's friend EXC_BAD_ACCESS. Of course this means the bad code wasn't anywhere near the actual crash. (And as an aside, surprising to me because I use ARC and therefore I don't write the retain and release code. So there's probably an ARC bug in here as well. Later I'll try to make a test app and submit a Radar.)
How did I find it? That in and of itself is a convoluted story and maybe worth relaying. I turned on NSZombieEnabled (in Xcode 4 you go to the Edit Scheme window and there's a checkbox in the Run/Diagnostics panel for Enable Zombie Objects) and discovered it was my TripMapViewController class receiving a respondsToSelector: message after it had been deallocated (and after the view wasn't onscreen anymore). This is a bit of a red herring because I use respondsToSelector: a fair amount so I scrubbed through all of my code and verified that I wasn't the culprit.
OK, I have to admit that stumped me for a moment. So it would appear that some other system thread is calling respondsToSelector with a pointer that it snuck past ARC. I did something hacky just to confirm the situation: I stashed a copy of the TripMapViewController in a static pointer, which should mean ARC no longer released the object. That worked and the crash stopped. Now what? After that I realized my object was still around and that I could overload respondsToSelector: and at least see the damn callstack. Turns out this controller gets a lot of respondsToSelector: messages; enough that you can't just stick a breakpoint in there. I did some more clunky things so that I could turn on a breakpoint after viewWillDisappear had been called. Sure enough, this big pile o' hacks worked for me: I could see the callstack of a bogus call. Problem is that it was all system stuff, with several calls just labeled "MKLongHash". If you Google MKLongHash you only get one hit which turns out to be a Stack Overflow thread about ARC and messages to zombie MKMapViews. Oh really?
Sure enough that's it. If you set the delegate of a MKMapView to a controller it is possible that ARC will incorrectly release the controller while some MKMap thing is still messing about. The solution provided in the article is to explicitly set and clear the delegate on viewWillAppear/viewWillDisappear. This worked for me. Maybe the next person who Googles for MKLongHash will find this helpful :-)