Reset signal handlers in forked children.

If a signal is delivered to a child process in between forking and
execing then it will trigger Chrome's signal handlers. This will
likely result in sadness.

BUG=44953

http://codereview.chromium.org/2452003/show

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48744 0039d316-1c4b-4281-b951-d872f2087c98

2 files changed, 11 insertions, 0 deletions

diff --git a/base/process_util_posix.cc b/base/process_util_posix.cc
index 2d65fad..af5ddcb 100644
--- a/base/process_util_posix.cc
+++ b/base/process_util_posix.cc
@@ -510,6 +510,13 @@ bool LaunchApp(
     RestoreDefaultExceptionHandler();
 #endif
 
+    // The previous signal handlers are likely to be meaningless in the child's
+    // context so we reset them to the defaults for now. http://crbug.com/44953
+    // These signal handlers are setup in browser_main.cc:BrowserMain
+    signal(SIGTERM, SIG_DFL);
+    signal(SIGHUP, SIG_DFL);
+    signal(SIGINT, SIG_DFL);
+
 #if 0
     // When debugging it can be helpful to check that we really aren't making
     // any hidden calls to malloc.
diff --git a/chrome/browser/browser_main.cc b/chrome/browser/browser_main.cc
index 2d959c3..34e945d 100644
--- a/chrome/browser/browser_main.cc
+++ b/chrome/browser/browser_main.cc
@@ -672,6 +672,10 @@ int BrowserMain(const MainFunctionParams& parameters) {
   action.sa_handler = SIGCHLDHandler;
   CHECK(sigaction(SIGCHLD, &action, NULL) == 0);
 
+  // If adding to this list of signal handlers, note the new signal probably
+  // needs to be reset in child processes. See
+  // base/process_util_posix.cc:LaunchApp
+
   // We need to handle SIGTERM, because that is how many POSIX-based distros ask
   // processes to quit gracefully at shutdown time.
   memset(&action, 0, sizeof(action));