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:
dispatch_queue_t reattemptQueue = dispatch_queue_create("reattempt", NULL);
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:
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
dispatch_queue_t currentQueue = dispatch_get_current_queue();
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:
dispatch_queue_t reattemptQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
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