The mutex was locked to ensure that the client object did not go away, but the client’s code may terminate the program which destroys the server_t instance and thereby the mutex itself, which would previously cause an assertion to trigger, since the mutex was locked during destruction.
In practice there is no issue with the mutex not being locked while accessing the client object, as “unregister_client” and “master_run” are both called from the main thread, except for tests, but here we do not unregister client objects before their requests have been handled.
The “proper” replacement for this API is to use the ServiceManagement framework’s SMJobBless() to bless our helper tool. In two of the three use-cases our helper tool is however regular shell commands, so it seems redundant to wrap these shell tools as helper tools we can install as launchd jobs.
We need this in a few places and while calling Gestalt() isn’t that much code, that function is deprecated in 10.8 and the alternative is a lot more code, so we don’t want to repeat that once we update the code.
20% of reported crashes are in launch_tbz which indirectly call oak::c_array. My hunch is that the c_str buffer is overwritten because the std::string which returned it has been disposed, this makes strdup() do a bad allocation / memory read.
This would likely be a race condition (wrt. the c_str buffer) and coincidentally the oak::c_array is called in a thread (when it crashes).
