block signals during fork
authorRich Felker <dalias@aerifal.cx>
Fri, 9 Aug 2013 03:17:05 +0000 (23:17 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 9 Aug 2013 03:17:05 +0000 (23:17 -0400)
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

index fb8a430add8505e175fd643409258164d5505fa6..1a82f4286bacdf24eef48e9a7107ba8fc9b79e60 100644 (file)
@@ -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;
 }