XTubeManager crash in background?

Question

I am experiencing a large amount of crashes in the XTubeManager (seems to be CFNetwork internal). Unfortunately the console logs are not available, only the call stack (see below).

Questions:

• I could imagine that my app crashes in the background, therefore no console logs are written, do you think this is a possibility?
• Do I have to handle backgroundTask expiration differently, e.g. by cancelling all my NSURLRequests? (see code below)

---

Background

I am regularly waking up in the background (or via background push) and running a background task like this:

NSString *myTaskName = @"some.random.task.name";
__block UIBackgroundTaskIdentifier taskID = [UIApplication.sharedApplication beginBackgroundTaskWithName:myTaskName expirationHandler:^{
    [UIApplication.sharedApplication endBackgroundTask:taskID];
    taskID = UIBackgroundTaskInvalid;
}];
dispatch_queue_t q = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(q,
    // doing some NSURLRequests stuff here
    [UIApplication.sharedApplication endBackgroundTask:taskID];
    taskID = UIBackgroundTaskInvalid;
});

This is usually called in applicationDidEnterBackground

CallStack

Thread : Crashed: com.apple.NSURLConnectionLoader
0  libobjc.A.dylib                0x183599b90 objc_msgSend + 16
1  CFNetwork                      0x184513300 XTubeManager::withTubeManager(CoreSchedulingSet const*, void (GlueTubeManager*) block_pointer) + 96
2  CFNetwork                      0x18451149c -[__NSURLSessionLocal _withConnectionCache_enqueueRequest:forProtocol:scheduling:options:] + 128
3  CFNetwork                      0x1845c3798 HTTPProtocol::asynchronouslyCreateAndOpenStream_WithMessage_AfterCookiesAndAuthenticatorHeaders(__CFHTTPMessage*) + 2000
4  CFNetwork                      0x1845c2ef8 HTTPProtocol::asynchronouslyAddAuthenticatorHeadersAndContinue(__CFHTTPMessage*) + 144
5  CFNetwork                      0x1845c4ba4 ___ZN12HTTPProtocol35asynchronouslyAddCookiesAndContinueEP15__CFHTTPMessage_block_invoke_2 + 28
6  libdispatch.dylib              0x18396d47c _dispatch_client_callout + 16

Answer 1

Some object down inside the NSURLConnection stack is disappearing. Some things to check:

• Make sure you aren't starting connections twice. (If you don't use ...startImmediately:NO, then make sure you never call start.)
• Make sure you aren't starting a connection and then releasing your last reference before the connection completes.
• Make sure you aren't using synchronous NSURLConnection calls (ever).

Beyond that, though, I've seen similar crashes before, and in many cases there's no obvious cause. Unless you're seeing a high frequency of crashes, there might not be any way to fix it other than to file a bug and hope Apple figures out a way to fix it for everyone.