iOS 14 CoreFoundation crash with EXC_BREAKPOINT

Are you using Multipeer Connectivity?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

For details , see my attached crash log

The interesting part is in 2 CFNetwork 0x00000001895e6c58 _BrowserCancel(__CFNetServiceBrowser*) + 120 (CFNetServiceBrowser.c:179)

which can be opened here: https://opensource.apple.com/source/CFNetwork/CFNetwork-129.18/NetServices/CFNetServiceBrowser.c.auto.html

/* static */ void
_BrowserCancel(__CFNetServiceBrowser* browser) {
	
	CFNetServiceBrowserClientCallBack cb = NULL;
	CFStreamError error;
	void* info = NULL;
	
	// Retain here to guarantee safety really after the browser release,
	// but definitely before the callback.
	CFRetain(browser);
	
	// Lock the browser
	__CFSpinLock(&browser->_lock);
	
	// If the browse canceled, don't need to do any of this.
	if (browser->_trigger) {
		
		// Save the callback if there is one at this time.
		cb = browser->_callback;
		
		// Save the error and client information for the callback
		memmove(&error, &(browser->_error), sizeof(error));
		info = browser->_client.info;
		
		// Remove the trigger from run loops and modes
		_CFTypeUnscheduleFromMultipleRunLoops(browser->_trigger, browser->_schedules);
		
		// Invalidate the run loop source that got here
		CFRunLoopSourceInvalidate((CFRunLoopSourceRef)(browser->_trigger));
		
		// Release the trigger now.
		CFRelease(browser->_trigger);
		browser->_trigger = NULL;
	}

	// Unlock the browser so the callback can be made safely.
	__CFSpinUnlock(&browser->_lock);
	
	// If there is a callback, inform the client of the finish.
	if (cb)
		cb((CFNetServiceBrowserRef)browser, 0, NULL, &error, info);
	
	// Go ahead and release now that the callback is done.
	CFRelease(browser);
}

the CFRunLoopSourceInvalidate causes the crash? There is a lock. But might be not correct?

Yes. using Multipeer Connectivity

OK. In that case my answer is that you should stop using Multipeer Connectivity. This is a long-standing bug and, while I can’t predict the future with 100% accuracy, I think it’s reasonable to infer future behaviour from past behaviour. In this case, you’re looking at a crashing bug that’s been around for at least 3 years old [1]. How long are you prepared to wait for a fix?

IMO Multipeer Connectivity should be officially deprecated in favour of Network framework [2]. If you’d like to make that transition:

• Check out the Building a custom peer-to-peer protocol sample code.

• If you get, stuck a new thread with the details. Tag it with Network so that I see it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Based on the age of this thread. I suspect that this bug has been around for much longer than that.

[2] And, to be clear, this is a personal opinion. I don’t set official Apple policy for this stuff. The official policy is in TN3151 Choosing the right networking API, which has to walk a fine line because Multipeer Connectivity isn’t officially deprecated.

Network framework is also compatible with Nearby Interaction and background?

I’m not particularly au fait with NI, but as a general rule Network framework can do anything that Multipeer Connectivity can do (and more). It’s really a question of focus. Multipeer Connectivity expects you to use the network in a specific way, and provides a high-level API based on that. Network framework is very generic. That means that in some cases you have to do a little more work to achieve a specific goal with Network framework than with Multipeer Connectivity. But, on the upside:

• It’s more reliable.

• It lets you design on-the-wire architecture that matches your problem domain.

If you have questions about how to achieve a specific goal, I recommend that you put them in a new thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"