#include <stdio.h> #include <sstream> int main(int ac, char **av) { std::__1::basic_ostringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > x; x << "How now brown cow"; return 0; } If I build this on macOS 12, and try to run the binary on macOS 11, it fails because that symbol is not present in /usr/lib/libc++.1.dylib. If I compile it on macOS 11, and run on 11 or later, it works. Is this correct behaviour? Since the dylib version didn't change, I would expect that to mean no ABI changes.

Why doesn't it have a way to see what the request was? You can see what extension it was for (the identifier property), but you can't tell whether it was for an installation, uninstallation, or properties request. Why is that?

We use CircleCI, so of course I've been spending the past week trying to get new secrets, profiles, certificates, and passwords in place. In the process, I went to generate a new Developer ID Application certificate. In the process of that I screwed up multiple times. So now I have four of them (five, actually -- one using the older cert so it expires Feb 1, 2027). They all have the same name. When I go to create a provisioning profile, there is no way to tell which one is which. No way to tell if they're being presented in the same order! Apple has told me they will not delete or revoke them, since it's not a security issue for these ones.

I'm trying to write a libcurl wrapper using the NSURL* interfaces. (Why? Because we're running into some problems with libcurl and I'd rather not rewrite all of the C++ code, so I thought I'd try wrapping a subset around NSURLSession et al.) One of the things we want to get is the IP address of the remote side (for both GET and POST). I can possibly live without this, but it's very useful for debug and performance information.

xctrace --template Leaks identified this as a leak:         NSString *uuid = [NSString stringWithUTF8String:connectionID];         NSData *contentData = [NSData dataWithBytes:data length:length];         id<ConnexctionProtocol> proxy = [connection asyncConnectionProxy];         [proxy handleData:uuid data:contentData]; return; (Which is to say: a few thousand objects show up in the Leaks pane, the stack for them goes up to the NSData creation, and Leaks apparently thinks it's never released.) That doesn't look like it should be a leak, with ARC? Which probably means I'm doing something wrong?

In response to my feedback submission, apple says that our transparent network proxy is stopping because, somehow, the file descriptor for com.apple.flow-divert is being closed. Only, they haven't (yet?) given any advice on how to debug that -- the extension is written in Swift, and by itself does not close any file descriptor. So I have no idea how I'd go about trying to debug that, let alone fix it. Anyone have any thoughts about this?

I couldn't find anything too recent, but everything seems to say that no, asl_search-like APIs are non-existent for os_log. And the source code for log isn't available so I can't see how it does it...

In order to set up an asynchronous query looking for a specific application, I have a predicate of:         NSPredicate *predicate = [NSPredicate predicateWithFormat:@"%K LIKE[cd] %@ AND %K = %@",                                                          @"kMDItemDisplayName", name,                                                          @"kMDItemContentType", UTTypeApplicationBundle.identifier]; I tested it with standalone code, and this did what I wanted -- finding applications with the given name. But recently, it seems to have stopped working. That query should be the equivalent of mdfind 'kMDItemDisplayName LIKE[cd] "Safari" AND kMDItemContentType == "com.apple.application-bundle"' but that gives me Failed to create query for 'kMDItemDisplayName LIKE[cd] "Safari" AND kMDItemContentType == "com.apple.application-bundle"'. If I drop the compound, and just do % mdfind 'kMDItemDisplayName LIKE[cd] "Safari"' then I get no output: % mdfind 'kMDItemDisplayName LIKE[cd] "Safari"' %  And yet clearly I do have Safari installed on my system. What am I doing wrong, or missing? Anyone?

I don't know how to go forward on this one: we have a test engineer who can, reliably, cause networking to simply stop working. Our app has 3 major components -- a proxy daemon, a containing UI app, and a network extension. Because I am lousy at using debuggers, the extension logs every single new flow it gets (to .debug), as well as a bunch more. When our engineer gets this problem, the proxy may crash a couple of times, but is still running; the extension is also still running, but no longer gets new flows. Networking outside the machine no longer works. But doing echo foo | nc 127.0.0.1 88 succeeds (or, at least, doesn't print any error -- and also doesn't get any log messages from the extension). I've got a sysdiagnose from it, as well as a bunch of logs, and all I can really see is that the proxy app restarted, and when it came back, it said there was no networking available. And that the extension stopped logging new flows at about the same time. I have not been able to reproduce this -- even though our engineer is using the same script I wrote to try to reproduce it, and he can, within an hour. (As opposed to my systems, which have been running for almost a day on both an M1 and Intel system.) Any ideas of things I should try looking for in the sysdiagnose?

Yes, actual process ID: on upgrades, our network extension sometimes decides to become completely incommunicado as far as XPC is concerned -- any attempt to send an XPC message to it results in "couldn't communicate with a helper application" or similar. The only workaround I've been able to come up with is unloading and reloading the extension. It was suggested that I try killing it. Which, great, but... how would I get it's pid? I do not at all feel comfortable launching pkill; I could get all the processes on the system and look for the name. But is there a way for the wrapping process to be able to get the pid?

We have a network extension. It is bundled in an app, that is launched as a launch agent for each user. When doing the install, the installer bootstraps the agent for each currently-logged-in console user. When the agent runs, it checks to see if it is the current active console user, and if so, goes through the process of activating the extension. This part works fine. But... if the installation is done while two users [haven't tried more than 2, sorry] are simultaneously logged in, SysPrefs gets launched for both users. Is this expected behaviour?

I had this a happen a long time ago, and I suspect that was due to the object not releasing due to its own retained objects. But now it's happening again. Now, I know this happening because I logged the address of the object, and there are different values alternating in the log. So my questions really are: How can I prevent this? How can I detect this?

consoleUser = SCDynamicstoreCopyConsoleUser(NULL, &uid, &gid); the string is empty, but not NULL. uid and gid are set properly. Any idea why this would happen? NB: it only happens from a LaunchAgent, for some reason; if I isolate the code in question, and run it via CLI, it works exactly as expected. And it only seems to happen for one person -- but for him, it happens on both Intel and Apple Silicon.

This is somewhat to my question at On reboot, two instances of faceless app - but slightly different focus. This is my understanding of how the system works, and please correct me if I'm wrong: A network extension can only be loaded by an application That application must contain the extension (in Contents/Library/SystemExtensions) Only the application instance that loads an extension can get VPN notifications (eg, NEVPNStatusDidChangeNotification) There does not appear to be a way to get the version of installed network extensions programmatically? When a second user logs in, and runs the containing app, and requests loading the extension, it does the normal replacement request. Given that... how is it supposed to handle multiple users (via Fast User Switching)?

We got a crash in some code, I had managed to miss this topic entirely somehow. This says: Pointer authentication can also expose latent bugs in existing code. In C++, it’s incorrect to call a virtual method using a declaration that differs from its definition. In practice, such calls typically succeed in arm64, but trigger a pointer authentication failure in arm64e. You might encounter this bug when using OS_OBJECT types like dispatch_queue_t and xpc_connection_t. You can’t pass instances of these types from C++ code to an Objective-C++ function (or vice versa) because they’re defined differently in Objective-C++ to support automatic reference counting (ARC). and, yes, we have both C++ and ObjC++ code, and a class does have a dispatch_queue_t member, and it does get passed around (although I don't think anything other than ObjC++ code touches the member), but... the documentation there says "you can't d this" but has absolutely no information on what you are supposed to do instead. Again, I've managed to miss this completely, and my network searching ability is pretty awful, so I assume I simply couldn't find documentation on it? (And I can't stream video very well where I am right now.)