Despite no feedback response, the issue seems to be resolved as of 15.1 or later -- we ran out tests for 55 hours with no insane mbuf leak, and, of course, no panic.

I was very curious why I'd never seen eslogger and it turns out it's because it was introduced more recently than my older systems. 😄 Confirmed that it shows the expected behavior on one machine, so I'll be poking at it. At least I know that it does show SIGKILL actions. Although I guess that's notification, not authorization...

Ok, MAYBE never mind: this may be some weirdness between LS and running under Xcode -- if I run the built app manually, outside of Xcode, then it works on the first attempt. At least on one attempt, anyway; need to poke at it a lot more. Ironically discovered whilst filing a feedback and verifying each of the steps.

No suggestions? I'll go file a feedback, I guess, because it repeatedly ignores the first drag&drop. Second and later, fine.

Which is beyond my (current, at least) capabilities. sigh.

I've no idea why it wouldn't. It's Safari. I even (just now) turned off content blockers for this site, and it still does this. How would I figure that out? (I have a couple of ad blockers, TamperMonkey, and 1Password as installed & active extensions.)

I get the same behaviour using https://developer.apple.com/forums -- just repeated several times in a row, by logging in in this window, then opening a new window and pasting https://developer.apple.com/forums into the address bar. So that's not it.

So it does help to drag the file to the right icon... (since I was debugging it under Xcode, but had the "real" one in my dock). That seems to do it better, but weirdly, it's not happening the first time I drag a file onto the icon. Also, I have this in the main view: .handlesExternalEvents(preferring: ["my-scheme"], allowing: ["my-scheme"]) // activate existing window if exists .onOpenURL { url in // stuff } and both the .openURL and the app delegate method are being triggered. I think this is probably due to confusion on my part, though.

Don't need it, obviously! (Of possible interest, though, I'm only interested in finding out information about our own processes, so I assume there's a way to get a task handle for those, even if it involves setting up some XPC between them.)

As always, @DTS Engineer is extremely helpful.

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.