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

Homo

By any chance do you use Branch.io integration in your app? – Unbolted

Nope unfortunately no – Homo

@ZacharyWest I'm seeing this too, and I'm using Branch. Also with the same sparse crash log. – Yean

@Yean It may be a coincidence, but I started seeing this crash when we integrated Branch (and not much else changed in this release). It's possible they are doing something to the networking stack that is causing this. – Unbolted

@ZacharyWest how often? This is a brand new app, but I've only a couple of reports on this crash so far. – Yean

@Yean 10-20 crashes/day - pretty rare. All iOS 9. – Unbolted

@ZacharyWest for me it's a major bug, with > 2k crashes per day. Pretty sure it's happening in the background, so that users don't really see it. But destroys all background activities – Homo

Alex from Branch.io here: nothing in that stack trace immediately jumps out to us as Branch-related, but if anyone manages to dig up further details, please let us know! support.branch.io – Rascality

do you have http pipelining enabled by chance? – Bindman

"XTubeManager" is a bit of an unfortunate name these days... – Chas

A month later I'm still seeing the crash, but very infrequently. I filed a bug report with Apple, not sure that I can think much else to be done at the moment. – Yean

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.

Vulcanology