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

[Tanu Kaskinen]

On Tue, 2018-04-10 at 16:50 +0200, René J.V. Bertin wrote:
> 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?

No, I probably just misunderstood your question. I interpreted the
question as "the referenced blog post is only about ObjC and fork(), so
why is the blog post relevant, given that PulseAudio isn't written in
ObjC?"

That's a question that I wondered at some point myself, and came to the
conclusion that if libpulse is used with an application written in
ObjC, then the ObjC runtime might have some effect on the fork()
restrictions also in libpulse, for example by setting some process
setting in the kernel that tightens the rules.

libpulse definitely doesn't need to call any ObjC APIs between fork()
and exec(), at least directly. libpulse does provide an atfork()
callback that applications can set, and the callback could do anything,
but it's unlikely that applications are actually using that callback.
(The callback is called from the child between fork() and exec().)

Wild speculation: maybe the ObjC runtime takes over the malloc()
function? So when pa_close_all() allocates memory from the heap, the
memory allocation enters the ObjC runtime and causes some bad thing
happening (it's actually unclear to me how the autospawning fails -
maybe the child process gets killed).

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk