A server with the specified hostname could not be found exception

App & System Services Networking
AndriiSulimenko OP
Created 1w
Replies 11
Boosts 0
Views 183
Participants 2

Hi, I have been working on the app that implements DNS Proxy Extension for a while now, and after a couple builds to TestFlight I noticed that I got a couple crashes that seem to be triggered by EXC_BREAKPOINT (SIGTRAP)

After some investigation, it was found that crashes are connected to CFNetwork framework. So, I decided to additionally look into memory issues, but I found the app has no obvious memory leaks, no memory regression (within recommended 25%, actual value is at 20% as of right now), but the app still uses 11mb of memory footprint and most of it (6.5 mb is Swift metadata).

At this point, not sure what's triggering those crashes, but I noticed that sometimes app will return message like this to the console (this example is for PostHog api that I use in the app):

Task <0ABDCF4A-9653-4583-9150-EC11D852CA9E>.<1> finished with error [18 446 744 073 709 550 613] Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={_kCFStreamErrorCodeKey=8, NSUnderlyingError=0x1072df0f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1003 "(null)" UserInfo={_kCFStreamErrorDomainKey=12, _kCFStreamErrorCodeKey=8, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 2ms using unknown from cache, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <0ABDCF4A-9653-4583-9150-EC11D852CA9E>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalUploadTask <0ABDCF4A-9653-4583-9150-EC11D852CA9E>.<1>"
), NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLStringKey=https://us.i.posthog.com/batch, NSErrorFailingURLKey=https://us.i.posthog.com/batch, _kCFStreamErrorDomainKey=12}

If DNS Proxy Provider uses custom DoH server for resolving packets, could the cache policy for URLSession be a reason?

I had a couple other ideas (HTTP3 failure, CFNetwork core issues like described here) but not sure if they are valid

Would be grateful if someone could give me a hint of what I should look at

Replies  11
Boosts  0
Views  183
Participants  2
DTS Engineer OP
Apple
6d
after a couple builds to TestFlight I noticed that I got a couple crashes that seem to be triggered by EXC_BREAKPOINT (SIGTRAP)

This usually means you’ve hit a trap. It’s common to see this in Swift code — for example, if you access an array out of bounds or force unwrap an optional that’s nil — but it can also be triggered by non-Swift code, including system frameworks.

After some investigation, it was found that crashes are connected to CFNetwork framework. So, I decided to additionally look into memory issues …

Why did you decide to do that? Did you have specific evidence that your CFNetwork issue was memory related?

Can you post a crash report showing this trap exception? See Posting a Crash Report for advice on how to do that.

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

0
AndriiSulimenko OP
6d

Hi, thank you for your response.

Here are two examples of the crash reports for EXC_BREAKPOINT (SIGTRAP)

crash report.txt

crash report (1).txt

Why did you decide to do that? Did you have specific evidence that your CFNetwork issue was memory related?

No, I didn't have specific evidence, however earlier I had crashes with EXC_BAD_ACCESS (SIGKILL) errors referencing to PAC. So I thought it'd a good idea to investigate possible memory issues. Additionally, some of the crashes were resolved by rewriting part of the networking module for DNS Proxy with async/await instead of completion handlers with Result.

0
DTS Engineer OP
Apple
5d

Thanks for the crash reports.

Both of those indicate memory corruption, not memory exhaustion. Specifically:

  • In the first you’re trapping in __CFCheckCFInfoPACSignature, indicating a pointer authentication check failed.

  • In the second you’re trapping in _xzm_xzone_malloc_tiny_outlined, which is because it’s detected borkage the malloc data structures.

In short, I think you have a memory management bug in your code, and I recommend that your apply the standard memory debugging tools.

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

0
AndriiSulimenko OP
5d

I see now. Quick question, could it be related to overuse of UserDefaults?

The reason I am asking is because some of the temporary data is stored in UserDefaults for my app.

I will give you an example. Because my app uses Content Filter (Filter Data Provider has sandbox restrictions), I wasn't able to use FileManager or CoreData for storing some information from Filter Data Provider because access was denied. So I had to use UserDefaults.

  • can't share the whole idea, but in a nutshell I needed to store resolved ips from flows

Additionally, I use UserDefaults for some data that is accessed from MDM config profile and shared to UI components via KVO

0
AndriiSulimenko OP
5d

Tried to add Address Sanitizer but received the same runtime issue as here

upd: fixed by disabling other diagnostics tools 🥲

0
AndriiSulimenko OP
5d

Not sure if this is right, please correct me if I am wrong here. One of the possible causes for my issue could also be concurrent access to one memory address?

Ideally would probably be to rewrite some code with FileManager under AppGroup for large data?

0
DTS Engineer OP
Apple
4d
One of the possible causes for my issue could also be concurrent access to one memory address?

Yes. Concurrency bugs can manifest as memory corruption.

could it be related to overuse of UserDefaults?

That’s unlikely. The UserDefaults API is not a common source of memory corruption issues.

I wasn't able to use FileManager or CoreData for storing some information from Filter Data Provider because access was denied. So I had to use UserDefaults.

Which provider is writing this data? And which provider is reading it?

A filter data provider should have read/write access to its own container. So, if you want to persist data within your filter data provider, any file system API should work for that.

OTOH, if you want to write data in one provider and read it in another, things get more complex.

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

0
AndriiSulimenko OP
4d

Which provider is writing this data? And which provider is reading it?

In my case, Filter Control Provider writes data received from MDM configuration profile, then Filter Data Provider reads this data to use it for flow filtering. But my Filter Data Provider also writes some data about intercepted flow, that is later used for resolving them.

0
AndriiSulimenko OP
4d

OTOH, if you want to write data in one provider and read it in another, things get more complex.

I think that's a great explanation for the problem I had with Core Data. Because my Content Filter is not limited by just two providers, I think target membership for custom controllers that add more logic to flow filtering could have granted access to these components for main target. Then, it makes sense why I was received errors for sandbox restrictions.

I guess my next steps would be ensuring that concurrent access is handled properly and maybe bringing back Core Data for Filter Data Provider

Thank you!

0
DTS Engineer OP
Apple
1d
In my case, Filter Control Provider writes data received from MDM configuration profile, then Filter Data Provider reads this data to use it for flow filtering.

OK. That should be possible by putting the data into an app group. The control provider will have read/write access to that app group; the data provider will only be able to read it.

And, yes, you will need some sort of concurrency control there (-:

But my Filter Data Provider also writes some data about intercepted flow, that is later used for resolving them.

As long as this only needs to be read back by the data provider, you’re all good. Just put the data into the data provider’s container.

You still might need concurrency control though, although it’s only intra-process concurrency control. That is, multiple threads within the data provider might be accessing this data and you have to make sure they don’t stomp on each other.

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

0
AndriiSulimenko OP
6h

OK. That should be possible by putting the data into an app group. The control provider will have read/write access to that app group; the data provider will only be able to read it.

And, yes, you will need some sort of concurrency control there (-:

Yep, that's exactly how I did it. My concurrency control for now is a shared container KVO with serial queue for read and async write for observed property within Content Filter scope.

And thank you for your previous response, it seems like the number of crashes decreased a lot for the new build, since I added some concurrency control for DNS Proxy Extension. It still requires some investigation but overall stability looks better

0
A server with the specified hostname could not be found exception
First post date Last post date
 
 
Q