Core Data lockup with parent/child contexts on iOS 5.1

I ran into an interesting Core Data lockup problem recently. It only arises on iOS 5.1.

I have a master-detail setup, and the master tableview has 3 different sorting schemes. I wrote a method for each of these schemes to create an NSFetchedResultsController, initialize it with proper sort descriptors, give it a cache name, and perform the initial fetch.

When the tableview appears, I fire off the appropriate method to get the NSFetchedResultsController I’ll use immediately. But then I wanted to warm up the caches for the other two modes, in a background GCD queue. Here’s what it looked like:

– (void)warmUpCachesExcepting:(NSInteger)dataviewMode


    dispatch_async( dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

        NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc]


        childContext.parentContext = self.staticdataMOC;

        if (dataviewMode != tailNumberDataviewMode) {

            @autoreleasepool {

                [[self class] tailNumberFetchedResultsControllerForContext:childContext




        if (dataviewMode != ownerDataviewMode) {

            @autoreleasepool {

                [[self class] registrantFetchedResultsControllerForContext:childContext




        if (dataviewMode != manufacturerDataviewMode) {

            @autoreleasepool {

                [[self class] makeAndModelFetchedResultsControllerForContext:childContext




        [childContext release];



Create a new managed object context, set its parent to my original MOC, go to work on the child. This code worked fine on iOS 6. When I switch sorting orders, the change is snappy. 

When I tested this code on an original iPad running iOS 5.1, the app would hang. I did some digging on Stack Overflow and other places, and saw comments suggesting that parent/child contexts had some problems on 5.1

As it turns out, I don’t need to pass results back to the parent MOC. I just wanted a separate context for my background thread. I changed the setup to create the new MOC and then point its persistent store coordinator back to the original MOC’s PSC.

                       NSManagedObjectContext *workingContext = [[NSManagedObjectContext alloc]


                       workingContext.persistentStoreCoordinator = self.staticdataMOC.persistentStoreCoordinator;

Works like a charm now. I didn’t dig deep enough to see exactly where and why I was hanging.

data capture from Yaesu FTM-350R



Yaesu’s FTM-350R mobile APRS radio has very sparse documentation on how to communicate with the radio. It’s possible to listen to the data output in 3 different formats: Packet, waypoints, or GPS output. Here are some captures of the various output formats, using a radio with the version 1.2 firmware update applied.

All of these files were capture from a Yaesu FTM-350R with firmware version 1.2. For all captures, the comm settings between radio and computer were 4800-N-8-1, XON/XOFF handshaking.


The “packet 9600” file was capture from the Puget Sound area’s two 9600 baud APRS channels on 144.350 and 440.800. “packet 1200” was captured on the 1200 baud frequency of 144.390.


The different modes were selected using the E16 menu, option 2: “GPS OUT’, “PACKET”, or “WAYPOINT”. The “startup” file was capture with “PACKET” chosen.


Here’s a brief excerpt of the Packet format. The full sample files are attached.

K7MHL-9>T7TSRQ,WW7RA,SOMTN,WIDE2* [12/21/10 12:16:36] <UI R>:
`2\ao C>/`"46}443.325MHz Mike HL_"


K7MHL-9>T7TSRQ,WW7RA,BALDI,WIDE2* [12/21/10 12:16:38] <UI R>: `2\ao C>/`"46}443.325MHz Mike HL_"

K7PAL-9>EH4PSW,WIDE1-1,WIDE2-1 [12/21/10 12:16:41] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA*,WIDE2-1 [12/21/10 12:16:42] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA,SOMTN,WIDE2* [12/21/10 12:16:43] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA,BALDI,WIDE2* [12/21/10 12:16:44] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

WW7RA>ID [12/21/10 12:16:45] <UI>: WW7RA/R DISABL/B

KB0CVX>T7PPQT,SOMTN,WIDE1* [12/21/10 12:16:47] <UI>: `2M<l#W@/ APRS AD7AB-9>4WPWVQ,BALDI*,WIDE2-1 [12/21/10 12:16:49] <UI R>: '29^l"3>/]"4n}TM-D700A at conference.


Hal N3YX

PACKET (monitoring 1200 baud frequency):

packet 1200 12-21-10.pdfPACKET (monitoring 9600 baud frequency):

packet 9600 12-21-10.pdf

Startup sequence:

startup 12-21-10.pdf

GPS output:

GPS 12-21-10.pdf

Waypoint output:

waypoints 12-21-10.pdf

Divisiveness and Dino Rossi’s campaign: “steal this election”?


The “Dino Rossi For Governor” signs with the subtitle “Don’t Let Seattle Steal This Election!” have been reported on before. But I was still disappointed to see this sign on US 101 near Sequim recently.

Someone who would condone this accusatory tone and pit one part of the state against another has no business trying to lead. Yes, I know the campaign claims they have nothing to do with the signs. But an aspiring leader worthy of the title ought to be able to persuade his followers to put a stop to this sort of garbage.

This leadership failure is just one more reason I’m supporting Gov. Gregoire for reelection.

Wil Shipley Kills 1,000,000 people: “The Mojave Experiment:” Bad Science, Bad Marketing

“The Mojave Experiment:” Bad Science, Bad Marketing: “Microsoft has managed to prove that if you have a friendly expert on a controlled machine (with Vista pre-installed) showing a carefully selected subset of Vista features to an ignorant XP user for a few minutes, the XP user will often say he finds Vista acceptable. Wow”

(Via Call Me Fishmeal..)

But even Scott Adams knows better than to pick on Vista, Wil:

Close Call: “If I mock Vista, and it has an impact on Microsoft stock value, then Bill Gates will have a few billion dollars less to spend on humanitarian projects. Therefore, the comic could end up killing a million people. Those people are all strangers, but still.”

(Via Blog.)

Lisp lives

In the 1990’s, I was the lead developer for a fairly large Lisp project, a simulation environment for animal behavior and habitat usage. I had a great time on that project, and I still miss working in Lisp (although Cocoa is almost as fun and almost as productive).

I was very happy to see this new survey of active Common Lisp implementations by Daniel Weinreb. It’s nice to see that good old Franz is still around, and I may yet get that old animal simulation code running under Mac OS X with Clozure’s OpenMCL.