iOS 14 CoreFoundation crash with EXC_BREAKPOINT

Hi,
I am facing a strange issue in my app with iOS14 there is a intermittent crash, i am using NetServiceBrowser for MDNS discovery not sure if that is causing the problem crash log has below information:

Crashed: com.apple.main-thread
0 CoreFoundation 0x1a906c4c4 CFAssertMismatchedTypeID + 108
1 CoreFoundation 0x1a8f7db0c
CFRunLoopSourceRemoveFromRunLoop + 298
2 CFNetwork 0x1a96255b0 CFNetServiceBrowserStopSearch + 460
3 CoreFoundation 0x1a8f81240 CFRUNLOOP
ISCALLINGOUTTOASOURCE0PERFORMFUNCTION + 24
4 CoreFoundation 0x1a8f81140
CFRunLoopDoSource0 + 204
5 CoreFoundation 0x1a8f80488
CFRunLoopDoSources0 + 256
6 CoreFoundation 0x1a8f7aa40
CFRunLoopRun + 776
7 CoreFoundation 0x1a8f7a200 CFRunLoopRunSpecific + 572
8 GraphicsServices 0x1bf075598 GSEventRunModal + 160
9 UIKitCore 0x1ab840004 -[UIApplication
run] + 1052
10 UIKitCore 0x1ab8455d8 UIApplicationMain + 164

Replies

We've been seeing a number of crashes with a similar assertion, but
related to the EAAccessory Framework.

These errors are unlikely to be related. You’re crashing for the same reason (CF has detected a type mismatch at runtime) but the cause of that type mismatch is very different.

Consider this snippet from the crashing thread’s backtrace:

Code Block
1 CoreFoundation … _CFAssertMismatchedTypeID + 100
2 CoreFoundation … CFRunLoopSourceSignal + 312
3 ExternalAccessory … -[EAInputStream _scheduleCallback] + 72
4 ExternalAccessory … -[EAInputStream _performAtEndOfStreamValidation] + 116


Frame 1 is the type mismatch, but note how frames 2 is different (in the other cases it was removing a run loop source) as are frames 3 and 4.

I recommend that you open a new thread for this and tag it with ExternalAccessory to see if anyone with EA experience (which I do not have, btw) chimes in.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Hello there,

Has anyone figured out the cause of this crash?
We are facing the same issue since iOS 14 (14.3 and 14.4) when using multipeer connectivity and MCNearbyServiceBrowser.

Thanks!

Our app uses Multipeer Connectivity and we've been experiencing this issue since iOS 14 was released.

One common theme is that the app is running in the background when the issue arrises and we get the crash.

Expected typeID 46 (CFRunLoopSource) does not match actual typeID 61 (CFSocket)

We've been trying to diagnose what is happening through our remote logging, but so far the cause of the issue has escaped us.

One common theme is that the app is running in the background when the
issue arrises and we get the crash.

You use Multipeer Connectivity in the background? Is that just because you don’t shut it down when you move to the background? Or because you actually need to use it in the background?

Multipeer Connectivity isn’t rated for use the background. Some parts of it will likely work as long as you guarantee that your process never gets suspended (as is generally true for out networking APIs). Other parts simply don’t make sense in the background.

Having said that, it shouldn’t crash )-:

Do you have an Apple crash report for this? If so, please post it here. Use the text attachment feature (the paperclip icon) to avoid clogging up the timeline.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Hi,

Would this Apple crash report help?

Thanks,


Would this Apple crash report help?

Yes, and no.

It’s clearly the same issue and it helped me track down the bug we’re using to track this (r. 60399638). However, that bug doesn’t offer any suggestions for how you might work around it.

Two factoids of note:
  • We’re seeing this reported by a number of different apps, suggesting that this is a bug in the system rather than a bug in the apps.

  • It’s likely that immediate cause of this crash was a change we made in iOS 14 to harden CF-level APIs against type mismatches (r. 14049993). So, this problem may have been occurring previously but iOS 14 is now detecting it reliably.

Oh, one other thing: It’s clear that this bug is triggered by a CF-level problem. That means it affects CFNetServiceBrowser and all the things layered on top of that, including NSNetServiceBrowser and Multipeer Connectivity. If you move to a different Bonjour API, one not based on CFNetServiceBrowser, it’s likely that you wouldn’t see this problem. That includes NWBrowser and the very low-level DNS-SD API (<dns_sd.h>). Of those, I’m going to recommend NWBrowser; Network framework is the future of (non-HTTP) networking on our platforms.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
  • So has this bug been fixed? iOS 14.6 still have this issue.

Add a Comment

So has this bug been fixed?

Our current thinking is that the bug mentioned above (r. 60399638) is specific to Multipeer Connectivity. Are you using that API? Or some other Bonjour API?

Share and Enjoy

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

  • Is there any update to the status of this bug (r. 60399638)? We are facing the same issue with Multipeer Connectivity on iOS 14. Are there any workarounds or an estimated timeline for a fix?

Add a Comment

Is there any update to the status of this bug (r. 60399638)?

No.

Are there any workarounds

As I said in my previous post, our current thinking is that this is specific to Multipeer Connectivity, and thus the ‘obvious’ workaround is to use a different API for your networking. My general recommendation is Network framework but if you want to talk specifics I encourage you to start a new thread with details about your network architecture.

an estimated timeline for a fix?

I can’t predict the future, alas. I will, however, note this problem started in iOS 14 and hasn’t been fixed in iOS 15, and let you draw your own conclusions.

Share and Enjoy

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

  • I appreciate your reply. Re-implementing hardly feels like a workaround, but if that is our best path forward, we will take it into consideration.

  • Is there any way to prioritize 60399638? Previously, we used the DNS-SD APIs for our networking, but when iOS 14 was in beta this functionality broke. We opened a feedback request (FB9028018), but it was not resolved in time for the release. We were advised at that time to use Multipeer, so we completely re-implemented our app's networking (which required updates to documentation and literature provided to our customers). Now, we're facing this issue less than 6 months later and have been given another suggestion to reimplement with a 3rd framework. As you can imagine, this is very frustrating for us and our users. We would much prefer to get this bug prioritized and resolved as it currently feels like we are running in circles.

Add a Comment