For some reason, launchd seems to stall when `[message release]` is called when message is NULL.
This only seems to be an issue with the newer source. The older source doesn't require this check. I'm worried that I might be overlooking an underlying issue...
* The XPC magic has changed to "@XPC" (at least on Catalina)
* Container entry counts are included in their content lengths
* When there are no descriptors to send (i.e. when the message is not complex), the XPC data appears immediately after the header (no descriptor count)
First, make xpc_log into a small wrapper over os_log; all it does differently is check whether to enable or disable XPC logging (based on whether we're in syslogd or something else that would cause a deadlock/loop).
Second, add xpc_assumes (and friends) for verifying assumptions for both debug and release builds and logging a message when one fails.
Third, make sure to unset the associatedConnection weak reference when deallocating dictionaries.
Another fix: use objc release instead of os_object_release_internal for releasing server peers (this way, if a user retains the connection, they can release it even after the server has released it).
Also, DISPATCH_MACH_DISCONNECTED is not the right place to release our internal reference. It can be called multiple times, once for each outstanding port and is not guaranteed to be called after DISPATCH_MACH_CANCELED. DISPATCH_MACH_CANCELED is actually the right place for this.
Finally, DISPATCH_MACH_NO_SENDERS should not release the old send port (that's what DISPATCH_MACH_DISCONNECTED is for).
However, bundled XPC services still don't work properly.
The problem is that bundled XPC service support needs to be implemented in launchd.
The open-source launchd sources are severely outdated, much like CoreFoundation.
The new launchd is based on libxpc and is closed-source.
We probably don't want to completely rewrite launchd, but at the very least, we do need to add support for new XPC-based features.
As noted in `plist.m`, the XML parsing implemented here is NOT robust, but it's good enough for the vast majority of files.
This commit also adds many new String methods. It also fixes an issue where syslogd would get stuck trying to send a message to itself due to our logging.
Also includes a serialization overhaul to be more object-oriented (each XPC object class worries about its own (de)serialization). The new serialization code also includes Mach port serialization (which we didn't have before).
The "test" service is not really a test; it's more of a sample. You have to test it out manually.
This commit is the first in the rewrite of libxpc. It implements the basic API (that is, the XPC object system and the most basic objects and collections). It also adds some tests for the basic API.
The current test suite uses ctest as the testing framework, but for future tests (such as for connections), it may be necessary to find something a little more robust (or roll our own).
Future commits will implement the rewritten connection system based on top of libdispatch's private Mach API, which is made specifically for this purpose (it even has certain methods marked as `4libxpc`).
This commit reorganizes the project to be a little more... organized ;)
It's a matter of preference, but I personally think separating sources and headers is more orderly. Various unnecessary sources that we inherited from NextBSD have also been removed.
We now use an exported symbols list to make our exported symbols match Apple's official libxpc (with the exception of those that we haven't stubbed/defined yet).
And finally, the {de,}serialization logic has been completely rewritten to match Apple's serialization format. The only possible issue there are doubles, which like the old code, we assume the double format is identical between the source machine and the receiving machine (which is probably a safe assumption, but should be avoided if possible).
Oh, and it also various little fixes, the most important of which is that creating a non-empty dictionary now works properly (we were previously doubling the entry count).
aslmanager uses libxpc, and using syslog causes a sort of deadlock because syslogd is waiting for aslmanager to respond, but aslmanager (via libxpc) is trying to talk to syslogd.
Unfortunately, syslogd still doesn't work as expected.
This fixes an error in libnotify that was making syslogd crash. `notify_client.c` was including `xpc/private.h` and trying to use `xpc_copy_entitlement_for_token`, which is declared in `launchd.h` and the compiler assumed a default return type of `int`, leading to the pointer returned by it being truncated and causing segfaults when it was used.
XPC bools and nulls were made into global to match their behavior in Apple's libxpc; users are allowed to compare XPC object pointers with the global XPC_BOOL_{TRUE,FALSE} constants, which are pointers to global variables, so this now allows that to work as expected.
xpc_pointer isn't documented *anywhere*, but it's used in Security. My best guess is that's it's just a pretty container for a pointer, which is fine for now, but I'll have to check the exact semantics later.
Unlike x86, there isn't an ARM specific implementation. Therefore, we need to rely on the generic implementation of OSAtomic. Since I have decided to rely on `libkern/OSAtomicDeprecated.h` for the time being, this header must be exposed to any function that uses (directly on indirectly) OSAtomic functions.
