GNU bug report logs - #33154
27.0.50; create_process on Darwin should not invoke setsid() after vfork() [PATCH]

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#33154: closed (27.0.50; create_process on Darwin should not
 invoke setsid() after vfork() [PATCH])
Date: Sat, 10 Nov 2018 17:06:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 10 Nov 2018 09:05:24 -0800
with message-id <46eebc4b-2c93-eeca-faa1-7fd041ed19ec <at> cs.ucla.edu>
and subject line Re: 27.0.50; create_process on Darwin should not invoke setsid() after vfork() [PATCH]
has caused the debbugs.gnu.org bug report #33154,
regarding 27.0.50; create_process on Darwin should not invoke setsid() after vfork() [PATCH]
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
33154: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33154
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50;
 create_process on Darwin should not invoke setsid() after vfork()
 [PATCH]
Date: Thu, 25 Oct 2018 22:30:12 +0300

This resulted from analysis of bug 33050.  To avoid repetition, here's
the message with explanation:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-10/msg00763.html

Suggested patch is below.

Thanks.

In GNU Emacs 27.0.50 (build 12, x86_64-apple-darwin17.7.0, NS appkit-1561.60 Version 10.13.6 (Build 17G65))
 of 2018-10-25 built on fgunbin.playteam.ru
Repository revision: f1f1687fcd8d48cd519c0f2977bcecbf394a7f01
System Description:  Mac OS X 10.13.6


diff --git a/src/process.c b/src/process.c
index 6cda4f27ac..1f8810927d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -2066,21 +2066,7 @@ create_process (Lisp_Object process, char **new_argv, Lisp_Object current_dir)
   int volatile forkerr_volatile = forkerr;
   struct Lisp_Process *p_volatile = p;
 
-#ifdef DARWIN_OS
-  /* Darwin doesn't let us run setsid after a vfork, so use fork when
-     necessary.  Also, reset SIGCHLD handling after a vfork, as
-     apparently macOS can mistakenly deliver SIGCHLD to the child.  */
-  if (pty_flag)
-    pid = fork ();
-  else
-    {
-      pid = vfork ();
-      if (pid == 0)
-	signal (SIGCHLD, SIG_DFL);
-    }
-#else
   pid = vfork ();
-#endif
 
   current_dir = current_dir_volatile;
   lisp_pty_name = lisp_pty_name_volatile;
@@ -2091,15 +2077,35 @@ create_process (Lisp_Object process, char **new_argv, Lisp_Object current_dir)
   p = p_volatile;
 
   pty_flag = p->pty_flag;
-
   if (pid == 0)
 #endif /* not WINDOWSNT */
     {
+#ifdef DARWIN_OS
+      /* Work around a macOS bug, where SIGCHLD is apparently
+	 delivered to a vforked child instead of to its parent.  See:
+	 https://lists.gnu.org/r/emacs-devel/2017-05/msg00342.html
+      */
+      signal (SIGCHLD, SIG_DFL);
+#endif
+
       /* Make the pty be the controlling terminal of the process.  */
 #ifdef HAVE_PTYS
       /* First, disconnect its current controlling terminal.
 	 Do this even if !PTY_FLAG; see Bug#30762.  */
+#ifdef DARWIN_OS
+      /* Darwin doesn't let us run setsid after a vfork, so use
+         TIOCNOTTY when necessary. */
+      {
+	int j = emacs_open (DEV_TTY, O_RDWR, 0);
+	if (j >= 0)
+	  {
+	    ioctl (j, TIOCNOTTY, 0);
+	    emacs_close (j);
+	  }
+      }
+#else
       setsid ();
+#endif
       /* Make the pty's terminal the controlling terminal.  */
       if (pty_flag && forkin >= 0)
 	{

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: Filipp Gunbin <fgunbin <at> fastmail.fm>, 33154-done <at> debbugs.gnu.org
Subject: Re: 27.0.50; create_process on Darwin should not invoke setsid()
 after vfork() [PATCH]
Date: Sat, 10 Nov 2018 09:05:24 -0800

Alan Third wrote:

> I only have two tests I know of to try here and they both pass

Thanks for checking. I installed the patch on the master branch and am marking 
this bug as done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.