GCD dispatch_after call causing SIGBUS signal

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

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.