D'oh! No man pages so I wasn't sure what flavor was supposed to be -- I ended up looking at some XNU code but clearly didn't check all the cases. Thanks!

Sorry to hijack, but that didn't work for me. I'm trying a command-line utility, doing: static size_t get_thread_count(pid_t pid) { mach_port_t me = mach_task_self(); mach_port_t task; kern_return_t res; thread_array_t threads; mach_msg_type_number_t n_threads; res = task_for_pid(me, pid, &task); if (res != KERN_SUCCESS) { fprintf(stderr, "Unable to get task for pid %d: %d\n", pid, res); return 0; } res = task_threads(task, &threads, &n_threads); if (res != KERN_SUCCESS) { fprintf(stderr, "Could not get threads: %d\n", res); return 0; } res = vm_deallocate(me, (vm_address_t)threads, n_threads * sizeof(*threads)); // Ignore error return n_threads; }``` and using an entitlements plist of and using codesign --sign - --entitlements ./ent.plist --deep ./t3 --force to get it in there, but it fails with error 5. (Even when run as root. 😄) This could be how I'm codesigning it, of course; I was just doing a simple CLI tool test first.

Yay that works! But how can I get thread count? I can't seem to use task_for_pid() (even with an Info.plist that has SecTaskAccess set to true).

I didn't really solve it -- it's a hacky work-around. When I call dio?.close()... it should close. It doesn't. And because it's busy doing one byte of I/O at a time, there was pending data; I had to change it to close it after a delay (0.5 seconds). I don't know what amount the other side is sending. My read-length is 1024 (this is my go-to length when I'm reading from a network), my sample case is 18 bytes in my unit test, it's written all at once, but because of the water marks, the read handler is called 18 times. Well, 19 because of the delayed .close(flags: .stop). If I set the water-marks to something other than 1, then it always waits until the length is available. Which doesn't work when the connection is interactive. Thus: Also, I really wish it would get the data available at once for the read, rather than 1 at a time.)

And yes, that seems to have fixed it. It's still very weird.

As far as I can tell, this is a conflict between the nhollman json library, and a set of formatter headers added in Xcode 16. But since it's C++, I can't figure out what exactly is going on, or how to work around it. But... something that is compiled with Xcode 15 for macOS 14, with a minimum deployment of 12.0, really should still work with Xcode 16 & macOS 15, shouldn't it?

See I always KNEW Xcode was out to get me it's just taken TWENTY FIVE YEARS to prove it! 😄

The thing is, I do have the right entitlements in it -- see my output. But I still have to manually notarize in this case? (Our actual product is all command-line and I wrote scripts for all of this, but then promptly forgot everything I wrote, as is of course expected.)

Well, that's the best way for Apple. It doesn't help me at all, although I guess there's no point to filing a TSI. 😄 My question at the beginning was whether anyone else has run into this, and if they have, did they have any mitigations (other than not including UDP in the includedRules set). I'd still love to know if anyone has, especially to the mitigations part. 😄

I went into far more details and analyses and question-asking in Transparent Proxy Provider, UDP, mbufs, and inevitable panics

Ok. I just took my simple extension test program (which sets up a TPP that returns false from both handleNew*Flow methods) and it exhibits the same behaviour. Again, only with UDP.

About 2.5 hours later: 50175/784366 mbufs in use: 50173 mbufs allocated to data 2 mbufs allocated to packet headers 734191 mbufs allocated to caches

Yeah, based on all of this, I think I'm going to take a stab at refactoring all of it to just use DispatchIO. If I end up choosing to pass it over XPC, I could just use the FileHandle and turn it into a DispatchIO on the other side.

Most this particular session has been in order to come up with a way to have tests for our transparent proxy provider that can be run without using the main extension -- so I rolled the networking code out, wrote a mimic of NEAppProxyFlow, and then wrote tests for it. It uses socket I/O to communicate with each side ("app" and "TPP"). Internally, it uses DispachIO to handle data sent from the "app", while it exposes the "TPP" side as a FileHandle (and it does that so that I could, if I needed to, pass it over XPC). This isn't the only way I could have implemented it, admittedly, but it grew out of my first approach, which was to use kqueue. (Oh, and I got the FileHandle issue solved -- the class behaves super badly if it gets closed more than once, so I isolated that code into a function, turned the object into an optional, and set it to nil after closing it.) Since I don't think I'll end up using XPC to pass the FileHandle around, I can probably turn it all into DispatchIO. I hadn't primarily because I kept getting crashes, and/or leaked file descriptors, but now that I can get the DispatchIO part working without crashes, it's time to revisit it.

Ok, using that information, I was able to reproduce it in a standalone program, which helped me track it down. (And then I had to deal with the cleanupHandler not being called, but I found that out and got it done.) Now I'm sometimes getting a crash: fileHandle?.readabilityHandler = { fh in let data = try fh.availableData print("Got \(data.count) bytes") } *** Terminating app due to uncaught exception 'NSFileHandleOperationException', reason: '*** -[NSConcreteFileHandle availableData]: Bad file descriptor' This only happens sometimes, in my tests.