The latest release of iOS 6 has “introduced” a pesky Cocoa Lumberjack bug. If you recall, Lumberjack is our favorite enhanced logging API for use with iPhone development. If you don’t recall, well… Lumberjack is our favorite enhanced logging API for use with iPhone development.
If you’ve done any web service development you may be familiar with the technique of starting a query on a asynchronous thread, like this:
[objc]
dispatch_queue_t reattemptQueue = dispatch_queue_create("reattempt", NULL);
dispatch_async(reattemptQueue, ^{
[self reattemptLogin];
});
[/objc]
In short, we’re trying to log in to a service and the initial attempt failed, so we’ll create a GCD queue called reattempt and then dispatch the call [self reattemptLogin]; on that queue. Our [self reattemptLogin] code does the following:
[objc]
-(void)reattemptLogin {
ENTRY_LOG;
[/objc]
and that’s really all we have to show you because, boom, it crashes right there! The error you will mostly see is EXC_BREAKPOINT against the code
[objc]
dispatch_queue_t currentQueue = dispatch_get_current_queue();
[/objc]
inside the Lumberjack source. Here’s the break where the exception was generated:
And here is the crash traceback.
There is actually a ticket opened in Github for this issue. As hinted at by the ticket, the workaround here is to, rather than create a new queue, get the global queue:
[objc]
dispatch_queue_t reattemptQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
[/objc]
Your application can still successfully dispatch an operation to a queue and not block the UI thread, but this time it won’t crash if you are doing logging.
What you may find is that your application works fine in a release mode since there is no logging with Lumberjack, but when you start your debug builds up again things start crashing for no apparent reason! Take a look and see if you are creating named queues with dispatch_queue_create and replace it with dispatch_get_global_queue!