GCD dispatch_after call causing SIGBUS signal - ios

Question

I'm using GCD's dispatch_after method when my application is being loaded to perform some behavior. The intended behavior is to wait 3 seconds from the end of applicationDidFinishLaunchingWithOptions to perform a selector that runs in a background queue.
I haven't experienced any crashes on my test devices, but I have user crash reports of uncaught SIGBUS signals, the cause being a BUS_ADRALN exception. From my understanding of this code, a BUS_ADRALN error indicates an address alignment error.
This is how I'm creating my timer:
double delayInSeconds = 3.0;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);
dispatch_after(popTime, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0),
^(void){
[self methodToPerformInBackground];
});
What could be causing this crash?
Since multithreading errors can be a strange sort of beast, I'm going to throw out some ideas that I've been tossing around in my head.
I'm calling this from within a call to [self performSelectorOnMainThread:withObject:waitUntilDone]. Is there something problematic about doing this within a selector called this way?
Since I'm calling dispatch_get_global_queue and not dispatch_create_queue, I don't need to retain the queue returned by this method. Is this reasoning correct?
In this code, self is the application delegate. Could the crash be caused trying to perform the block after the application enters the background or terminates? Would the application automatically clean up any dispatched blocks upon closing?
Something inside the method being called is causing the crash, but GCD doesn't provide a stack trace to it.
Edit: I'd rather not include the code that's called in the block, since I'm not convinced that's the main problem anyway. Here is the stack trace. The crash on thread 0 makes it seem as though the issue was in GCD, not the code called in the block.
Edit #2: I have strange news to share after going through more crash reports. This crash is only appearing for users running iOS 4.2.X and below. Since GCD is supported for iOS 4.0 and later, my guess is there was a bug patched in 4.3.
Thread 0 Crashed:
0 libSystem.B.dylib 0x35e5fb10 _dispatch_retain + 0
1 libSystem.B.dylib 0x35e5df8c dispatch_after_f + 80
2 libSystem.B.dylib 0x35e5e070 dispatch_after + 72
3 MyApplication 0x0000466c -[MyApplicationDelegate applicationDidFinishLaunchingPart2:] (MyApplicationDelegate.m:366)
4 CoreFoundation 0x37538f79 -[NSObject(NSObject) performSelector:withObject:] + 25
5 Foundation 0x35171e6d __NSThreadPerformPerform + 273
6 CoreFoundation 0x375518d1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
7 CoreFoundation 0x37521ecd __CFRunLoopDoSources0 + 385
8 CoreFoundation 0x375216f9 __CFRunLoopRun + 265
9 CoreFoundation 0x3752150b CFRunLoopRunSpecific + 227
10 CoreFoundation 0x37521419 CFRunLoopRunInMode + 61
11 GraphicsServices 0x33e76d24 GSEventRunModal + 196
12 UIKit 0x3591d57c -[UIApplication _run] + 588
13 UIKit 0x3591a558 UIApplicationMain + 972
14 MyApplication 0x00003024 main (main.m:113)
Thread 1:
0 libSystem.B.dylib 0x35d8f974 kevent + 24
1 libSystem.B.dylib 0x35e5dd70 _dispatch_queue_invoke + 104
2 libSystem.B.dylib 0x35e5d790 _dispatch_worker_thread2 + 128
3 libSystem.B.dylib 0x35de6978 _pthread_wqthread + 400
Thread 2:
0 libSystem.B.dylib 0x35de72fc __workq_kernreturn + 8
Thread 3:
0 libSystem.B.dylib 0x35d5b3b0 mach_msg_trap + 20
1 CoreFoundation 0x37521f83 __CFRunLoopServiceMachPort + 95
2 CoreFoundation 0x37521787 __CFRunLoopRun + 407
3 CoreFoundation 0x3752150b CFRunLoopRunSpecific + 227
4 CoreFoundation 0x37521419 CFRunLoopRunInMode + 61
5 WebCore 0x3318bd1c _ZL12RunWebThreadPv + 532
6 libSystem.B.dylib 0x35de5b4c _pthread_start + 372
Thread 4:
0 libSystem.B.dylib 0x35d5b3b0 mach_msg_trap + 20
1 CoreFoundation 0x37521f83 __CFRunLoopServiceMachPort + 95
2 CoreFoundation 0x37521787 __CFRunLoopRun + 407
3 CoreFoundation 0x3752150b CFRunLoopRunSpecific + 227
4 CoreFoundation 0x37521419 CFRunLoopRunInMode + 61
5 Foundation 0x3517ec55 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] + 217
6 Foundation 0x3515cb91 -[NSThread main] + 49
7 Foundation 0x35155b97 __NSThread__main__ + 915
8 libSystem.B.dylib 0x35de5b4c _pthread_start + 372

Answer 1

DISPATCH_QUEUE_PRIORITY_BACKGROUND is an iOS 5.0+ feature. If you try to use it on iOS 4.x it will be NULL (which will crash when you try to retain it, since GCD is a C-library and it is not safe to use NULL the way it is to use nil in objective-c). See this answer for more info. The solution is to use low priority instead, or use preprocessor directives to switch between the two.