[R-SIG-Mac] Forking issues in Mavericks

Simon Urbanek simon.urbanek at r-project.org
Thu Oct 31 14:22:32 CET 2013

On Oct 30, 2013, at 6:13 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote:

> On Wed, Oct 30, 2013 at 2:57 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> Ah, you're running it in R.app?
> Well this was the easiest way to show it; the same problem appears when forking form inside httpuv or so.

AFAIR httpuv itself is not fork-safe, so it may be a different issue - in cases like this the exact way the process is setup plays an important role. This appears to be the case for another reason - see below.

>> Anyway, my hunch was correct - it's libcurl crashing in SSL trying to use CF.
> I wish there was at least way to make situations like these fail more
> gracefully... it's fine if the misbehaved child proc is killed, but
> it's a bit painful that it also takes down its parent(s). There's
> nothing we can do to catch these situations before it is too late?

I can't think of a way right now, because we have no idea that some 3rd party is calling CF.

BTW: I was trying to cause a fork segfault with something like mcparallel(quartz()), but to my great astonishment it works in 10.9. So apparently it is now safe to call CF after fork() as long as you didn't initialize CF before forking. That's actually great news, because the server (e.g. in my use-case Rserve) just has to make sure that no CF is called and then all is well. Also if the child dies, it does NOT take down the parent - I suspect that there is more involved in your case, so we can take it offline if you want to provide the complete example of your issue.


More information about the R-SIG-Mac mailing list