[pulseaudio-discuss] PulseAudio autospawn fails on macOS 10.13 (High Sierra)

[René J.V. Bertin]

On Tuesday April 10 2018 15:15:52 Tanu Kaskinen wrote:

>> I think there are several alternatives to look at
>> - get rid of all unsafe API calls between fork and exec; this is what
>> we did with KDE's KInit framework for instance. I have not had any
>> feedback (yet) that the result doesn't work on 10.13 .
>
>Is calling close() safe? If it is, then this option seems feasible. The

The close() you'd use to close open file descriptors? I think it's safe, yes.

See also the discussion and various iterations during the review of my kinit modifications:
https://git.reviewboard.kde.org/r/126161/
As I said, it's long enough ago that I forgot all the details, but I do remember that at some point the fork+exec was actually done in a helper application which was probably executed via system(), or which only needed safe API calls before being exec()'ed.

>>   Why would PA need to call ObjC APIs while auto-spawning?
>
>PA doesn't have any ObjC code, but applications using libpulse may
>have. I don't know what the ObjC runtime does that affects the forking
>behaviour of libpulse, maybe it sets some process settings in the
>kernel.

Wait, are you saying that even the parent process cannot call anything "unsafe" before the child has done an exec() after forking off? The don't-do-unsafe-things-between-fork-and-exec thing isn't new, but I've always known it as something affecting the child only.
If not, I don't understand. I suppose the fork() and exec() calls are made in a function somewhere in libpulse, and the application using libpulse shouldn't be able to execute anything after and "on the wrong side of" the fork(). Not at least if you impose that the libpulse call leading to the auto-spawn has to be made from the main thread and before creating background threads that might do incompatible things. Doesn't sound like an unreasonable constraint to me.

fork() doesn't necessarily create a fully & properly initialised clone of the parent process, it's easy to imagine that the ObjC runtime could rely on things that are invalid in the forked-off child process. Sending messages to objects (= invoking ObjC class functions) would be a likely suspect; the child process probably inherits pointers to addresses in the parent's address space which are off-limits to the child.

R