From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 16 07:00:35 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF9E237B401 for ; Wed, 16 Apr 2003 07:00:34 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F77343F3F for ; Wed, 16 Apr 2003 07:00:34 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h3GE0YUp023150 for ; Wed, 16 Apr 2003 07:00:34 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3GE0Yxw023149; Wed, 16 Apr 2003 07:00:34 -0700 (PDT) Date: Wed, 16 Apr 2003 07:00:34 -0700 (PDT) Message-Id: <200304161400.h3GE0Yxw023149@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Anton Berezin Subject: Re: bin/49087: Signals lost in programs linked with libc_r X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Anton Berezin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 14:00:35 -0000 The following reply was made to PR bin/49087; it has been noted by GNATS. From: Anton Berezin To: Enache Adrian Cc: FreeBSD-gnats-submit@FreeBSD.org, fjoe@FreeBSD.org, deischen@FreeBSD.org, marcel@FreeBSD.org Subject: Re: bin/49087: Signals lost in programs linked with libc_r Date: Wed, 16 Apr 2003 15:56:42 +0200 On Mon, Mar 10, 2003 at 11:28:34PM +0200, Enache Adrian wrote: > FreeBSD seems to lose blocked signals in programs linked > with libc_r. This bug shows up when running the perl > test suite with a multithreaded perl ( i.e. linked to > libc_r.so ), more precisely at test 11 of ext/POSIX/t/posix.t. > -----< sig.c >--------------------------------------------------- > #include > #include > #include > > void sighup(int dummy) > { > kill(getpid(),SIGINT); > sleep(1); > printf("sigint delayed ...\n"); > } > > void sigint(int dummy) > { > printf("SIGINT !\n"); > } > > struct sigaction act; > > int main() > { > act.sa_handler = sighup; > sigaddset(&act.sa_mask, SIGINT); > sigaction(SIGHUP, &act, NULL); > signal(SIGINT,sigint); > kill(getpid(),SIGHUP); > sleep(2); > printf("*\n"); > return 0; > } > ----------------------------------------------------------------- > Any pointers appreciated. Please try the following patch (tested an identical patch on 4.8; not tested with -current): Index: uthread_sig.c =================================================================== RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_sig.c,v retrieving revision 1.45 diff -u -r1.45 uthread_sig.c --- uthread_sig.c 5 Mar 2003 04:28:08 -0000 1.45 +++ uthread_sig.c 16 Apr 2003 13:45:36 -0000 @@ -257,6 +257,7 @@ void (*sigfunc)(int, siginfo_t *, void *); int saved_seqno; sigset_t saved_sigmask; + sigset_t sigset; /* Invoke the signal handler without going through the scheduler: */ @@ -288,8 +289,26 @@ * Only restore the signal mask if it hasn't been changed by the * application during invocation of the signal handler: */ - if (curthread->sigmask_seqno == saved_seqno) + if (curthread->sigmask_seqno == saved_seqno) { curthread->sigmask = saved_sigmask; + + /* + * Just like in _pthread_sigmask(), check if + * there are pending signals for the running + * thread or process that aren't blocked. + * This avoids losing signals when sigaction() with + * non-empty sa_mask is used. + */ + sigset = curthread->sigpend; + SIGSETOR(sigset, _process_sigpending); + SIGSETNAND(sigset, curthread->sigmask); + if (SIGNOTEMPTY(sigset)) + /* + * Call the kernel scheduler which will safely + * install a signal frame for the running thread: + */ + _thread_kern_sched_sig(); + } } /* I would be *glad* if a person which knows uthreads better than I do reviews the patch and tells me that I am wrong and where I am wrong. :-) That's why I am Ccing three random uthread_sig.c committers. Cheers, %Anton. -- Perl is strongly typed, it just has very few types. -- Dan Sugalski