XTubeManager crash in background?

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

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.