Strategies for tracking down _objc_msgSend crashes inside dispatch_sync block

Question

I'm receiving crash reports (via the excellent Hockey) indicating that I've got a memory problem in some code that's called inside a dispatch_sync block (or at least that's how I'm interpreting the crash report snippet below). I've not been able to recreate this crash on my test devices at all (so strategies like NSZombieEnabled are not helping me). I'm happy to make code changes to make the crash reports more informative (and ultimately solve the underlying issue), I just don't know where to start. Any thoughts?

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xb000000c
Crashed Thread:  7
...
Thread 7 Crashed:
0   libobjc.A.dylib            0x3979bb66 _objc_msgSend + 6
1   libdispatch.dylib          0x39c898fb _dispatch_barrier_sync_f_invoke + 27
2   App                        0x00260f23 __48-[Foo displayLinkCallback]_block_invoke + 147
3   libdispatch.dylib          0x39c85103 _dispatch_call_block_and_release + 11
4   libdispatch.dylib          0x39c894bf _dispatch_async_redirect_invoke + 111
5   libdispatch.dylib          0x39c8a7e5 _dispatch_root_queue_drain + 225
6   libdispatch.dylib          0x39c8a9d1 _dispatch_worker_thread2 + 57
7   libsystem_pthread.dylib    0x39db4dff __pthread_wqthread + 299

The dispatch_sync is provided a static serial queue. Is it possible that the _objc_msgSend is indicating a problem referencing this queue rather than some issue inside the block?

To pre-empt the obvious, I'm seeing no indication of deadlocks in these crash reports.

Update (8th Oct '13)

Adding code as requested (method and variable names changed, but still close to original). I suspect the issue is somewhere around the copying of foo. My hope was that this question would yield stategies for debugging this error. If 'check line by line' is the best strategy for debugging _objc_msgSend crashes inside dispatch_sync block then it's a little sad, but I'll take any help I can get at this point.

Also, I should point out that the crash I am investigating only ever happens on single-core devices and intermittently at that.

- (void) displayLinkCallback
{
    dispatch_async(_frameDispatchQueue, ^{
        if ([_lock tryLock])
        {
            dispatch_sync(_renderQueueSerial, ^{
                NSObject *fooCopy = nil;
                BOOL bar = NO;

                // prevents deallocation during subsequent copy
                // _foo is set and/or its child objects changed 
                // many times per second by other threads)
                NSObject *foo = _foo;

                // copy foo 
                fooCopy = [foo copy];

                bar = [self needsBarGivenFoo:fooCopy];
                if (bar)
                {
                    _lastFoo = foo;
                    [self goFoo:fooCopy];
                }
                else
                {
                    [self noFoo:fooCopy];
                }
            });
            [_lock unlock];
        }
    });
}

Answer 1

I would suggest starting your analysis on those references in your source files. This symbolicated crashlog suggests that your crash stems from something in the displayLinkCallback method in the Foo class. You should probably start your investigation there.

It's telling you had a segmentation violation. But it's hard to diagnose further without seeing the source code for that method.