From d4d6d6f322cd13cfca2b179345cdcf67997c3529 Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Thu, 8 Aug 2013 23:17:05 -0400 Subject: block signals during fork there are several reasons for this. some of them are related to race conditions that arise since fork is required to be async-signal-safe: if fork or pthread_create is called from a signal handler after the fork syscall has returned but before the subsequent userspace code has finished, inconsistent state could result. also, there seem to be kernel and/or strace bugs related to arrival of signals during fork, at least on some versions, and simply blocking signals eliminates the possibility of such bugs. --- src/process/fork.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'src') diff --git a/src/process/fork.c b/src/process/fork.c index fb8a430a..1a82f428 100644 --- a/src/process/fork.c +++ b/src/process/fork.c @@ -13,7 +13,9 @@ weak_alias(dummy, __fork_handler); pid_t fork(void) { pid_t ret; + sigset_t set; __fork_handler(-1); + __block_all_sigs(&set); ret = syscall(SYS_fork); if (libc.main_thread && !ret) { pthread_t self = __pthread_self(); @@ -22,6 +24,7 @@ pid_t fork(void) libc.threads_minus_1 = 0; libc.main_thread = self; } + __restore_sigs(&set); __fork_handler(!ret); return ret; } -- cgit v1.2.1