Block signals while forking so they aren't run in the child process.

base/process/launch_posix.cc

Index: base/process/launch_posix.cc
diff --git a/base/process/launch_posix.cc b/base/process/launch_posix.cc
index 3708af6bac417b49e4015fed93eb49966ed78363..1388a0e1524bef2dc57c981025b25fe7ae915dcd 100644
--- a/base/process/launch_posix.cc
+++ b/base/process/launch_posix.cc
@@ -394,6 +394,14 @@ bool LaunchProcess(const std::vector<std::string>& argv,
   if (options.environ)
     new_environ.reset(AlterEnvironment(*options.environ, GetEnvironment()));
 
+  sigset_t full_sigset;
+  sigfillset(&full_sigset);
+  sigset_t old_sigset;
+  if (pthread_sigmask(SIG_BLOCK, &full_sigset, &old_sigset) != 0) {

[Markus (顧孟勤), 2013/08/01 01:20:54]

In principle, I believe this works OK. But you are technically skirting
real-close to undefined behavior.

sigfillset() might set signals that are not actually defined. Linux happens to
have exactly 32 regular signals and 32 real-time signals. So, setting the full
mask does in fact affect exactly all signals. Not more, not less.

But this isn't necessarily true for all platforms.

Also, you are trying to block things like SIGKILL and SIGSTOP. This is not
actually possible.

In general, Linux tends to be nice and ends up doing what you meant rather than
what you told it to do (i.e. it ignores SIGKILL and SIGSTOP) in the signal mask.

Finally, glibc reserves at least one real-time signal for internal use by
pthreads. It will generally wrap all signal-related system calls to filter out
attempts to change this signal.

Summarizing all of the above, I don't actually require that you change this
code, as it is likely to work fine. But I would really like to see a unittest
that verifies that you don't get unexpected behavior.

[Markus (顧孟勤), 2013/08/01 01:20:54]

And now for a nitpick:

It is actually not possible to safely call fork() in a multi-threaded
application. So, if we were doing things correctly, you should be
single-threaded by the time you get here. And that of course means you should
have called sigprocmask() instead of pthread_sigmask().

But we all know this isn't happening :-(

[mdempsky_google, 2013/08/01 16:25:05]

https://code.google.com/p/chromium/issues/detail?id=36678 seems to suggest
Chromium depends on forking in a multi-threaded app.
Is there a difference between sigprocmask() and pthread_sigmask() on Linux? 
POSIX says they're the same except sigprocmask() can only be used in a
single-threaded process (whereas pthread_sigmask() can be used in
single-threaded or multi-threaded processes), and on OpenBSD they're backed by
the same system call.

(Well, and pthread_sigmask is in -lpthread instead of -lc, but I'm under the
possibly mistaken impression that Chromium code will be linking against
-lpthread anyway.)

[mdempsky_google, 2013/08/01 16:25:05]

I expect sigfillset() + pthread_sigmask() should be safe, but I'll check with
the austin group mailing list to be sure.
Agreed, but also it's not an error:

"It is not possible to block those signals which cannot be ignored. This shall
be enforced by the system without causing an error to be indicated."

http://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html
Yep, OpenBSD does that too.  I don't think it should be a problem here though.
Sure.  What sort of unittest did you have in mind?

+    DPLOG(ERROR) << "pthread_sigmask";
+    return false;
+  }
+
   pid_t pid;
 #if defined(OS_LINUX)
   if (options.clone_flags) {
@@ -404,6 +412,12 @@ bool LaunchProcess(const std::vector<std::string>& argv,
     pid = fork();
   }
 
+  if (pid != 0) {
+    if (pthread_sigmask(SIG_SETMASK, &old_sigset, NULL) != 0) {
+      NOTREACHED();
+    }
+  }
+
   if (pid < 0) {
     DPLOG(ERROR) << "fork";
     return false;
@@ -469,6 +483,9 @@ bool LaunchProcess(const std::vector<std::string>& argv,
 #endif  // defined(OS_MACOSX)
 
     ResetChildSignalHandlersToDefaults();
+    if (pthread_sigmask(SIG_SETMASK, &old_sigset, NULL) != 0) {
+      NOTREACHED();
+    }
 
 #if 0
     // When debugging it can be helpful to check that we really aren't making