From owner-freebsd-threads@FreeBSD.ORG Mon Nov 18 11:06:58 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58C1B23 for ; Mon, 18 Nov 2013 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B400B209B for ; Mon, 18 Nov 2013 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAIB6wIh009240 for ; Mon, 18 Nov 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAIB6wU8009238 for freebsd-threads@FreeBSD.org; Mon, 18 Nov 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Nov 2013 11:06:58 GMT Message-Id: <201311181106.rAIB6wU8009238@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/180652 threads [patch] compat32 problem in clock_getcpuclockid2 o threa/180496 threads clock_gettime() does not return CPU-time for zombie pr o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/30464 threads [patch] pthread mutex attributes -- pshared 19 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Nov 19 07:40:00 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B09E67DC for ; Tue, 19 Nov 2013 07:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE7629CE for ; Tue, 19 Nov 2013 07:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAJ7e0AB030984 for ; Tue, 19 Nov 2013 07:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAJ7e0uE030983; Tue, 19 Nov 2013 07:40:00 GMT (envelope-from gnats) Resent-Date: Tue, 19 Nov 2013 07:40:00 GMT Resent-Message-Id: <201311190740.rAJ7e0uE030983@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Thomas Eckardt Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7FC576E for ; Tue, 19 Nov 2013 07:33:20 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B79F129AD for ; Tue, 19 Nov 2013 07:33:20 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rAJ7XKXJ073613 for ; Tue, 19 Nov 2013 07:33:20 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rAJ7XKAg073609; Tue, 19 Nov 2013 07:33:20 GMT (envelope-from nobody) Message-Id: <201311190733.rAJ7XKAg073609@oldred.freebsd.org> Date: Tue, 19 Nov 2013 07:33:20 GMT From: Thomas Eckardt To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: threads/184073: wrong signal delivery to multithreaded processes in Perl X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 07:40:00 -0000 >Number: 184073 >Category: threads >Synopsis: wrong signal delivery to multithreaded processes in Perl >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 19 07:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Thomas Eckardt >Release: 9,2 >Organization: thockar >Environment: FreeBSD assp.nospam.org 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD assp.nospam.org 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Fri Sep 27 03:52:52 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 >Description: using (any) threaded perl (5.10 ... 5.18) and any freebsd version 8.x (or gt) the following happens: If a Perl script starts multiple threads (iThreads) - but at least one thread, all OS signals like 'kill -INT PID' are sent to the last started thread - NOT to the parent thread like expected. freebsd versions below version 8 are not tested Perl versions below 5.10 are not tested because of known Perl issue >How-To-Repeat: start multiple iThreads in Perl (interactive) - try to terminate or interrupt the script via keyboard or from another process using 'kill -SIG PID' - this will not work. I have a nice small perl script available to force/show the issue. Tell me if you need it. >Fix: No workaround. The last started Perl child thread must send the received SIG to the parent thread. How ever, this makes it very hard to use signals for inter-thread communication and controlling >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Tue Nov 19 09:00:01 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8B8B709 for ; Tue, 19 Nov 2013 09:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A79BE2E3C for ; Tue, 19 Nov 2013 09:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAJ901AE052459 for ; Tue, 19 Nov 2013 09:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAJ901OB052457; Tue, 19 Nov 2013 09:00:01 GMT (envelope-from gnats) Date: Tue, 19 Nov 2013 09:00:01 GMT Message-Id: <201311190900.rAJ901OB052457@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: "Daniel M. Eischen" Subject: Re: threads/184073: wrong signal delivery to multithreaded processes in Perl X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: "Daniel M. Eischen" List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 09:00:01 -0000 The following reply was made to PR threads/184073; it has been noted by GNATS. From: "Daniel M. Eischen" To: bug-followup@FreeBSD.org, Thomas.Eckardt@thockar.com Cc: Subject: Re: threads/184073: wrong signal delivery to multithreaded processes in Perl Date: Tue, 19 Nov 2013 03:40:34 -0500 There is no guarantee in POSIX that the main thread receives a signal sent to the process if multiple threads (including the main thread) have the signal unblocked. The only way to guarantee signal delivery to a specific thread is to send it directly to the desired thread, have all threads other than the desired thread mask the signal, or be blocked in sigwait{info}() from the desired thread at the time of signal delivery. You are relying on behavior that is not specified by the standard. From owner-freebsd-threads@FreeBSD.ORG Thu Nov 21 21:15:55 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C5BC94B; Thu, 21 Nov 2013 21:15:55 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 095A726D1; Thu, 21 Nov 2013 21:15:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rALLFkpI074541; Thu, 21 Nov 2013 23:15:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rALLFkpI074541 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rALLFkvl074540; Thu, 21 Nov 2013 23:15:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Nov 2013 23:15:46 +0200 From: Konstantin Belousov To: Vitaly Magerya Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler Message-ID: <20131121211546.GQ59496@kib.kiev.ua> References: <528DFEE6.6020504@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JeIqLcbgB5JjL5AU" Content-Disposition: inline In-Reply-To: <528DFEE6.6020504@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 21:15:55 -0000 --JeIqLcbgB5JjL5AU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 21, 2013 at 02:39:02PM +0200, Vitaly Magerya wrote: > Hi, folks. I'm investigating a test case failure that devel/boehm-gc > has on recent FreeBSD releases. The problem is that a signal > handler registered for SIGUSR1 is sometimes called with signum=3D0, > which should not be possible under any conditions. >=20 > Here's a simple test case that demonstrates this behavior: >=20 > /* Compile with 'c99 -o example example.c -pthread' > */ > #include > #include > #include > #include >=20 > void signal_handler(int signum, siginfo_t *si, void *context) { > if (signum !=3D SIGUSR1) { > printf("bad signal, signum=3D%d\n", signum); > exit(1); > } > } >=20 > void *thread_func(void *arg) { > return arg; > } >=20 > int main(void) { > struct sigaction sa =3D { 0 }; > sa.sa_flags =3D SA_SIGINFO; > sa.sa_sigaction =3D signal_handler; > if (sigfillset(&sa.sa_mask) !=3D 0) abort(); > if (sigaction(SIGUSR1, &sa, NULL) !=3D 0) abort(); > for (int i =3D 0; i < 10000; i++) { > pthread_t t; > pthread_create(&t, NULL, thread_func, NULL); > pthread_kill(t, SIGUSR1); Side note. pthread_kill(3) call behaviour is undefined if pthread_create(3) in the line before failed. > } > return 0; > } >=20 > Under FreeBSD 9.2-RELEASE amd64 I pretty consistently get > "signum=3D0" from this program, but you may need to run it a few > times or increase the number of iterations to see the same. >=20 > Interestingly enough, I don't see this behavior under 9.0-RELEASE. >=20 > So, any ideas what the problem here is? It happens when libthr deferred signal handling path is taken for signal delivery and for some reason the code inside the deferred path called into rtld for symbol binding. Than, rtld lock is locked, some code in rtld is executed, and rtld lock is unlocked. Unlock causes _thr_ast() run, which results in the nested check_deferred_signal() execution. The check_deferred_signal() clearks si_signo, so on return the same signal is delivered one more time, but is advertized as signo zero. The _thr_rtld_init() approach of doing dummy calls does not really work, since it is not practically possible to enumerate the symbols needed during signal delivery. My first attempt to fix this was to increment curthread->critical_count around the calls to check_* functions in the _thr_ast(), but it causes reverse problem of losing _thr_ast() runs on unlock. I ended up with the flag to indicate that deferred delivery is running, so check_deferred_signal() should avoid doing anything. A delicate moment is that user signal handler is allowed to modify the passed machine context to result the return from the signal handler to cause arbitrary jump, or just do longjmp(). For this case, I also clear the flag in thr_sighandler(), since kernel signal delivery means that nested delivery code should not run right now. Please try this. diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_privat= e.h index 83a02b5..c6651cd 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -433,6 +433,9 @@ struct pthread { /* the sigaction should be used for deferred signal. */ struct sigaction deferred_sigact; =20 + /* deferred signal delivery is performed, do not reenter. */ + int deferred_run; + /* Force new thread to exit. */ int force_exit; =20 diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c index 415ddb0..57c9406 100644 --- a/lib/libthr/thread/thr_sig.c +++ b/lib/libthr/thread/thr_sig.c @@ -162,6 +162,7 @@ thr_sighandler(int sig, siginfo_t *info, void *_ucp) act =3D _thr_sigact[sig-1].sigact; _thr_rwl_unlock(&_thr_sigact[sig-1].lock); errno =3D err; + curthread->deferred_run =3D 0; =20 /* * if a thread is in critical region, for example it holds low level lock= s, @@ -320,14 +321,18 @@ check_deferred_signal(struct pthread *curthread) siginfo_t info; int uc_len; =20 - if (__predict_true(curthread->deferred_siginfo.si_signo =3D=3D 0)) + if (__predict_true(curthread->deferred_siginfo.si_signo =3D=3D 0 || + curthread->deferred_run)) return; =20 + curthread->deferred_run =3D 1; uc_len =3D __getcontextx_size(); uc =3D alloca(uc_len); getcontext(uc); - if (curthread->deferred_siginfo.si_signo =3D=3D 0) + if (curthread->deferred_siginfo.si_signo =3D=3D 0) { + curthread->deferred_run =3D 0; return; + } __fillcontextx2((char *)uc); act =3D curthread->deferred_sigact; uc->uc_sigmask =3D curthread->deferred_sigmask; --JeIqLcbgB5JjL5AU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSjngBAAoJEJDCuSvBvK1BKx0QAJjAmJSh9i2IQC6e8pF1QXJG P6lTmX3WpLVdnPAA5ord/KoiBCaNJQ4w2YaEWOzuP3o4GHX70dYLY9HWHuwgMhei NzS+xOCdzZcPDI68ZghJ/N/67oJSlC9i/N4RLdgDqaBpElYrOKk1pmXqpQ/216op XinMrpR5oR4TvXJ80dNCsGzc5xQ0J9LW5TjYf3rzHSJSaYWO6jSIUwDrb6kLxtVA 7enT9j8rMO+HbXgWNNcXMBTAfo+2PabK/33twemiX7dbzGTQapbVK6RU9MYBYO0N 2Sa6YI0Zd5SFJyXLLggPi/Qop/mGIrsCgd2ICOsGnBYtc5qGpeFZkbKB8OnRdw02 u4HWokfnaE6eH+ktipA9+nbpAGL3MCsHgSZBLoIKDX0YWmqvEMM6wHdrJWWwIfEB /YJp8iHGwbrjtXx4ddUqa/30BRU1HzDImPafbAOvVdjLKFQozpHPJFwRhX+2NEA/ TA7PlXXLDVXc4wE7eP0Lo/8Vpnhk/Wv5Xz2a97F6IzdeOZpbuQwLaFf5eOJD77z9 8J1hhwE//c7nlk+9ovvRvqOdXyGeQSZaW22BRNu4VjYW/Cs5uaSGBCfPKJe99DGx 4tl3vaP28nnhQRH3reqyE/fJtfaJkMrGccO2EYVbkibaLWMEMBmLQ57no4TXrdWS BU5IUgDGkfqq4DKVpL87 =jCRC -----END PGP SIGNATURE----- --JeIqLcbgB5JjL5AU-- From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 03:55:55 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90A6B92A; Fri, 22 Nov 2013 03:55:55 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7085324B5; Fri, 22 Nov 2013 03:55:55 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAM3tskd068692; Fri, 22 Nov 2013 03:55:54 GMT (envelope-from davidxu@freebsd.org) Message-ID: <528ED5D3.1030906@freebsd.org> Date: Fri, 22 Nov 2013 11:56:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130416 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> In-Reply-To: <20131121211546.GQ59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Vitaly Magerya , threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 03:55:55 -0000 On 2013/11/22 05:15, Konstantin Belousov wrote: > On Thu, Nov 21, 2013 at 02:39:02PM +0200, Vitaly Magerya wrote: >> Hi, folks. I'm investigating a test case failure that devel/boehm-gc >> has on recent FreeBSD releases. The problem is that a signal >> handler registered for SIGUSR1 is sometimes called with signum=0, >> which should not be possible under any conditions. >> >> Here's a simple test case that demonstrates this behavior: >> >> /* Compile with 'c99 -o example example.c -pthread' >> */ >> #include >> #include >> #include >> #include >> >> void signal_handler(int signum, siginfo_t *si, void *context) { >> if (signum != SIGUSR1) { >> printf("bad signal, signum=%d\n", signum); >> exit(1); >> } >> } >> >> void *thread_func(void *arg) { >> return arg; >> } >> >> int main(void) { >> struct sigaction sa = { 0 }; >> sa.sa_flags = SA_SIGINFO; >> sa.sa_sigaction = signal_handler; >> if (sigfillset(&sa.sa_mask) != 0) abort(); >> if (sigaction(SIGUSR1, &sa, NULL) != 0) abort(); >> for (int i = 0; i < 10000; i++) { >> pthread_t t; >> pthread_create(&t, NULL, thread_func, NULL); >> pthread_kill(t, SIGUSR1); > Side note. pthread_kill(3) call behaviour is undefined if pthread_create(3) > in the line before failed. > >> } >> return 0; >> } >> >> Under FreeBSD 9.2-RELEASE amd64 I pretty consistently get >> "signum=0" from this program, but you may need to run it a few >> times or increase the number of iterations to see the same. >> >> Interestingly enough, I don't see this behavior under 9.0-RELEASE. >> >> So, any ideas what the problem here is? > > It happens when libthr deferred signal handling path is taken for signal > delivery and for some reason the code inside the deferred path called > into rtld for symbol binding. Than, rtld lock is locked, some code in > rtld is executed, and rtld lock is unlocked. Unlock causes _thr_ast() > run, which results in the nested check_deferred_signal() execution. > The check_deferred_signal() clearks si_signo, so on return the same > signal is delivered one more time, but is advertized as signo zero. > > The _thr_rtld_init() approach of doing dummy calls does not really work, > since it is not practically possible to enumerate the symbols needed > during signal delivery. > > My first attempt to fix this was to increment curthread->critical_count > around the calls to check_* functions in the _thr_ast(), but it causes > reverse problem of losing _thr_ast() runs on unlock. > > I ended up with the flag to indicate that deferred delivery is running, > so check_deferred_signal() should avoid doing anything. A delicate > moment is that user signal handler is allowed to modify the passed > machine context to result the return from the signal handler to cause > arbitrary jump, or just do longjmp(). For this case, I also clear the > flag in thr_sighandler(), since kernel signal delivery means that nested > delivery code should not run right now. > > Please try this. > > diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h > index 83a02b5..c6651cd 100644 > --- a/lib/libthr/thread/thr_private.h > +++ b/lib/libthr/thread/thr_private.h > @@ -433,6 +433,9 @@ struct pthread { > /* the sigaction should be used for deferred signal. */ > struct sigaction deferred_sigact; > > + /* deferred signal delivery is performed, do not reenter. */ > + int deferred_run; > + > /* Force new thread to exit. */ > int force_exit; > > diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c > index 415ddb0..57c9406 100644 > --- a/lib/libthr/thread/thr_sig.c > +++ b/lib/libthr/thread/thr_sig.c > @@ -162,6 +162,7 @@ thr_sighandler(int sig, siginfo_t *info, void *_ucp) > act = _thr_sigact[sig-1].sigact; > _thr_rwl_unlock(&_thr_sigact[sig-1].lock); > errno = err; > + curthread->deferred_run = 0; > > /* > * if a thread is in critical region, for example it holds low level locks, > @@ -320,14 +321,18 @@ check_deferred_signal(struct pthread *curthread) > siginfo_t info; > int uc_len; > > - if (__predict_true(curthread->deferred_siginfo.si_signo == 0)) > + if (__predict_true(curthread->deferred_siginfo.si_signo == 0 || > + curthread->deferred_run)) > return; > > + curthread->deferred_run = 1; > uc_len = __getcontextx_size(); > uc = alloca(uc_len); > getcontext(uc); > - if (curthread->deferred_siginfo.si_signo == 0) > + if (curthread->deferred_siginfo.si_signo == 0) { > + curthread->deferred_run = 0; > return; > + } > __fillcontextx2((char *)uc); > act = curthread->deferred_sigact; > uc->uc_sigmask = curthread->deferred_sigmask; > The patch looks fine to me. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 10:22:44 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD393B0E; Fri, 22 Nov 2013 10:22:44 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CDE7E27FE; Fri, 22 Nov 2013 10:22:43 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id z5so765996lbh.17 for ; Fri, 22 Nov 2013 02:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F56WM0o7sF1cHguprHuxlEqMssyHnKayRWPaALttQuw=; b=myeDvG4mrYhmXeDBWPXGSLOsbjE1E0CktNRcRXVqssRB5oq1jYcgixI8Zh3gv8EXhz siSY84JBnabHjqI99IHP1pQJkEAKi+SahSnn1J3CA/Vg2KUVJzYcMrx4NK+Plqw9furG 8EU8Vw8tfl5+ujF2WALUhopKkll2zcdW0zLHqJOf/oSKBPnbfXP4+XVfUA0GaC5yUC1Q Y3rHue95NiM5EowYOsJzB9AkI/B/ApuVh1D8XNUEMNBbXVkju/UK5MBqDML79FzBgVaB tpvEoJYmh4nTkTLeZBhUTjuJxrpTDKNsk82E9HVFSuHA7LG06dkSD1GNPa9c6CJ+LCV5 cr0A== X-Received: by 10.112.143.3 with SMTP id sa3mr8630181lbb.12.1385115761816; Fri, 22 Nov 2013 02:22:41 -0800 (PST) Received: from [172.29.2.131] (195-248-173-117.static.vega-ua.net. [195.248.173.117]) by mx.google.com with ESMTPSA id vz9sm26433975lbb.17.2013.11.22.02.22.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 02:22:40 -0800 (PST) Message-ID: <528F3062.8040105@gmail.com> Date: Fri, 22 Nov 2013 12:22:26 +0200 From: Vitaly Magerya User-Agent: Thunderbird MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> In-Reply-To: <20131121211546.GQ59496@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 10:22:44 -0000 On 2013-11-21 23:15, Konstantin Belousov wrote: > Please try this. > > diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h > [...] > diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c > [...] Yeah, applied to 9.2-RELEASE, this fixes the issues I had; thank you. Will you commit it and will it make it's way into 10-RELEASE? From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 11:56:28 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 793A7F32; Fri, 22 Nov 2013 11:56:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFA792F64; Fri, 22 Nov 2013 11:56:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAMBuI53059924; Fri, 22 Nov 2013 13:56:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAMBuI53059924 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAMBuIBl059923; Fri, 22 Nov 2013 13:56:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Nov 2013 13:56:18 +0200 From: Konstantin Belousov To: Vitaly Magerya Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler Message-ID: <20131122115618.GZ59496@kib.kiev.ua> References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> <528F3062.8040105@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hwm514xwU++9Zw4g" Content-Disposition: inline In-Reply-To: <528F3062.8040105@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 11:56:28 -0000 --hwm514xwU++9Zw4g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 22, 2013 at 12:22:26PM +0200, Vitaly Magerya wrote: > On 2013-11-21 23:15, Konstantin Belousov wrote: > > Please try this. > >=20 > > diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_pr= ivate.h > > [...] > > diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c > > [...] >=20 > Yeah, applied to 9.2-RELEASE, this fixes the issues I had; thank you. > Will you commit it and will it make it's way into 10-RELEASE? Sure I will commit it after testing. It is too premature to talk about MFC, before the reasonable testing period in HEAD after commit. --hwm514xwU++9Zw4g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSj0ZhAAoJEJDCuSvBvK1BPD4P/AwPqZZC7h+Y8qI7u1GFqPku 4E4ePSll/quaDXonal8Kh8xhmzIKmruf1D8UI8rh0xlKt8fwBeaXRqUjJQyMHrmP hPISOsevAlbN6GhftgqeEGa3v5mcwuz88RRPNxrfV/nRKdd8NRElQtbBVgVkatIr F5MmOst7CChRrjmt+g5StdzEUXUcfm2togS5gvuxhZukEuWMqz56KZ/20SP7PvAG A0lP/gbhOAZIlEhQ9/r8hBif/Sld42V7rRVr9PQr3ncAXVuICAcAoduVuhP/r/zH ZqlSUbuTCBIsCH5dUT/Wcj77VIxV8amYzeAf/kRS8fFGlVOq2/tiTovaiFPpzmMH CMamm+npBq26sZN3EhUckCmkbvXRWvevhyCTuBTon1rLK4gzI0YaYPx/PucEmsZq UHus/X2Ude9NWG/yubPgq1M9ZcaWSTxrMAnBreZL+VIJlMgwEZuJPJ+L6hH3we9p +Zp8Pf8cDFw9UeekKfepYDROKOpQJ3LJhfSyygzER2aDLTgQJ+DHzdUC1AxDa9Z8 TrXSxdQvH7WkPZRlQfPjmXCw2iD7AsfHsiRpIPGlo/rF5eUxBesELGck6OQ+gMx9 j5CXraBBz+uahhRJkP4ERgnDHGiEHOsT3eH9QXI799imd4IodvlC/krDGlBObPcV GfctHyU6tLHkKgkbiZQ5 =pBj7 -----END PGP SIGNATURE----- --hwm514xwU++9Zw4g-- From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 13:36:09 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 057ED2AC; Fri, 22 Nov 2013 13:36:09 +0000 (UTC) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89B0324E8; Fri, 22 Nov 2013 13:36:08 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 060391203C8; Fri, 22 Nov 2013 14:35:54 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id D2507CB4E; Fri, 22 Nov 2013 14:35:53 +0100 (CET) Date: Fri, 22 Nov 2013 14:35:53 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler Message-ID: <20131122133553.GA28457@stack.nl> References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131121211546.GQ59496@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, threads@freebsd.org, Vitaly Magerya , davidxu@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 13:36:09 -0000 On Thu, Nov 21, 2013 at 11:15:46PM +0200, Konstantin Belousov wrote: > On Thu, Nov 21, 2013 at 02:39:02PM +0200, Vitaly Magerya wrote: > > Hi, folks. I'm investigating a test case failure that devel/boehm-gc > > has on recent FreeBSD releases. The problem is that a signal > > handler registered for SIGUSR1 is sometimes called with signum=0, > > which should not be possible under any conditions. > > Here's a simple test case that demonstrates this behavior: > > /* Compile with 'c99 -o example example.c -pthread' > > */ > > #include > > #include > > #include > > #include > > > > void signal_handler(int signum, siginfo_t *si, void *context) { > > if (signum != SIGUSR1) { > > printf("bad signal, signum=%d\n", signum); > > exit(1); > > } > > } > > > > void *thread_func(void *arg) { > > return arg; > > } > > > > int main(void) { > > struct sigaction sa = { 0 }; > > sa.sa_flags = SA_SIGINFO; > > sa.sa_sigaction = signal_handler; > > if (sigfillset(&sa.sa_mask) != 0) abort(); > > if (sigaction(SIGUSR1, &sa, NULL) != 0) abort(); > > for (int i = 0; i < 10000; i++) { > > pthread_t t; > > pthread_create(&t, NULL, thread_func, NULL); > > pthread_kill(t, SIGUSR1); > Side note. pthread_kill(3) call behaviour is undefined if pthread_create(3) > in the line before failed. > > > } > > return 0; > > } > > Under FreeBSD 9.2-RELEASE amd64 I pretty consistently get > > "signum=0" from this program, but you may need to run it a few > > times or increase the number of iterations to see the same. > > Interestingly enough, I don't see this behavior under 9.0-RELEASE. This is because the bug was introduced with AVX support. (It also occurs on systems without AVX.) > > So, any ideas what the problem here is? > It happens when libthr deferred signal handling path is taken for signal > delivery and for some reason the code inside the deferred path called > into rtld for symbol binding. Than, rtld lock is locked, some code in > rtld is executed, and rtld lock is unlocked. Unlock causes _thr_ast() > run, which results in the nested check_deferred_signal() execution. > The check_deferred_signal() clearks si_signo, so on return the same > signal is delivered one more time, but is advertized as signo zero. > The _thr_rtld_init() approach of doing dummy calls does not really work, > since it is not practically possible to enumerate the symbols needed > during signal delivery. > My first attempt to fix this was to increment curthread->critical_count > around the calls to check_* functions in the _thr_ast(), but it causes > reverse problem of losing _thr_ast() runs on unlock. > I ended up with the flag to indicate that deferred delivery is running, > so check_deferred_signal() should avoid doing anything. A delicate > moment is that user signal handler is allowed to modify the passed > machine context to result the return from the signal handler to cause > arbitrary jump, or just do longjmp(). For this case, I also clear the > flag in thr_sighandler(), since kernel signal delivery means that nested > delivery code should not run right now. This analysis suggests an easier approach: just move the check for deferred_siginfo.si_signo == 0 downward. If __fillcontextx2 or sysarch need to be looked up by rtld, the resulting _thr_ast() will invoke the signal handler and the original call to check_deferred_signal() will do nothing. This patch fixes the problem for me on stable/9 and head. Index: lib/libthr/thread/thr_sig.c =================================================================== --- lib/libthr/thread/thr_sig.c (revision 258178) +++ lib/libthr/thread/thr_sig.c (working copy) @@ -326,12 +326,12 @@ check_deferred_signal(struct pthread *curthread) uc_len = __getcontextx_size(); uc = alloca(uc_len); getcontext(uc); - if (curthread->deferred_siginfo.si_signo == 0) - return; __fillcontextx2((char *)uc); act = curthread->deferred_sigact; uc->uc_sigmask = curthread->deferred_sigmask; memcpy(&info, &curthread->deferred_siginfo, sizeof(siginfo_t)); + if (curthread->deferred_siginfo.si_signo == 0) + return; /* remove signal */ curthread->deferred_siginfo.si_signo = 0; handle_signal(&act, info.si_signo, &info, uc); -- Jilles Tjoelker From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 15:21:06 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9E8EFD1; Fri, 22 Nov 2013 15:21:06 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D39602AEE; Fri, 22 Nov 2013 15:21:05 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id el20so1078928lab.9 for ; Fri, 22 Nov 2013 07:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xy+5XmsAdvZzZrW1Wqwxo9XR1IpG1jW73LOi83n/Ges=; b=cMTB7LLUIrYQIu0u69NufN+d4Spfy5iRxyMyMmBRWfVJdBb0S5c7s/QDRteiO5YlUF P992K7n6ghyRU2Zr0BhSq56MmgpvWRbM95FLzsSKAsDByx8K5q8zAna77mgbYei1C7Ao qdzTR8oYIV4C05px9refgM/o7RzzLuIUE7YWetdfrD2+Pm/elqM6toVCsdkZNJ0H2HHd rtSR7FGHZUSvTBPiqw1DMW2TO9nIfCvYShzzfLnpslM77ikjEDB8/x4bMeEVd9Ki5UG5 CvOiwqC51xuKz6WMmcYdI5pl+Ke5egDF1+6D3z+lUZFtAtVHr7l0QivaQyOq28fjJa9v R4Cg== X-Received: by 10.152.115.230 with SMTP id jr6mr1318172lab.45.1385133663854; Fri, 22 Nov 2013 07:21:03 -0800 (PST) Received: from [172.16.0.2] (tx97.net. [85.198.160.156]) by mx.google.com with ESMTPSA id k3sm27320892lbs.0.2013.11.22.07.21.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 07:21:02 -0800 (PST) Message-ID: <528F765A.8040306@gmail.com> Date: Fri, 22 Nov 2013 17:20:58 +0200 From: Vitaly Magerya User-Agent: Thunderbird MIME-Version: 1.0 To: Jilles Tjoelker , Konstantin Belousov Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> <20131122133553.GA28457@stack.nl> In-Reply-To: <20131122133553.GA28457@stack.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 15:21:06 -0000 On 11/22/2013 15:35, Jilles Tjoelker wrote: > This patch fixes the problem for me on stable/9 and head. > > Index: lib/libthr/thread/thr_sig.c > =================================================================== > --- lib/libthr/thread/thr_sig.c (revision 258178) > +++ lib/libthr/thread/thr_sig.c (working copy) > @@ -326,12 +326,12 @@ check_deferred_signal(struct pthread *curthread) > uc_len = __getcontextx_size(); > uc = alloca(uc_len); > getcontext(uc); > - if (curthread->deferred_siginfo.si_signo == 0) > - return; > __fillcontextx2((char *)uc); > act = curthread->deferred_sigact; > uc->uc_sigmask = curthread->deferred_sigmask; > memcpy(&info, &curthread->deferred_siginfo, sizeof(siginfo_t)); > + if (curthread->deferred_siginfo.si_signo == 0) > + return; > /* remove signal */ > curthread->deferred_siginfo.si_signo = 0; > handle_signal(&act, info.si_signo, &info, uc); > I can confirm that this also solves the problems I'm seeing. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 22 18:39:53 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 117E0145; Fri, 22 Nov 2013 18:39:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 842552652; Fri, 22 Nov 2013 18:39:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAMIdgQ8044050; Fri, 22 Nov 2013 20:39:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAMIdgQ8044050 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAMIdgnB044049; Fri, 22 Nov 2013 20:39:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Nov 2013 20:39:42 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Problem with signal 0 being delivered to SIGUSR1 handler Message-ID: <20131122183942.GB59496@kib.kiev.ua> References: <528DFEE6.6020504@gmail.com> <20131121211546.GQ59496@kib.kiev.ua> <20131122133553.GA28457@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rmx1G5GNWS01lHd9" Content-Disposition: inline In-Reply-To: <20131122133553.GA28457@stack.nl> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, threads@freebsd.org, Vitaly Magerya , davidxu@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:39:53 -0000 --rmx1G5GNWS01lHd9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 22, 2013 at 02:35:53PM +0100, Jilles Tjoelker wrote: > This analysis suggests an easier approach: just move the check for > deferred_siginfo.si_signo =3D=3D 0 downward. If __fillcontextx2 or sysarch > need to be looked up by rtld, the resulting _thr_ast() will invoke the > signal handler and the original call to check_deferred_signal() will do > nothing. >=20 > This patch fixes the problem for me on stable/9 and head. >=20 > Index: lib/libthr/thread/thr_sig.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libthr/thread/thr_sig.c (revision 258178) > +++ lib/libthr/thread/thr_sig.c (working copy) > @@ -326,12 +326,12 @@ check_deferred_signal(struct pthread *curthread) > uc_len =3D __getcontextx_size(); > uc =3D alloca(uc_len); > getcontext(uc); > - if (curthread->deferred_siginfo.si_signo =3D=3D 0) > - return; > __fillcontextx2((char *)uc); > act =3D curthread->deferred_sigact; > uc->uc_sigmask =3D curthread->deferred_sigmask; > memcpy(&info, &curthread->deferred_siginfo, sizeof(siginfo_t)); > + if (curthread->deferred_siginfo.si_signo =3D=3D 0) > + return; > /* remove signal */ > curthread->deferred_siginfo.si_signo =3D 0; > handle_signal(&act, info.si_signo, &info, uc); >=20 I do not like this. It is similar to what I did initially when I debugged the problem, but the duplicated calls to getcontext(2) and sysarch(2) stayed out as a sore in ktrace. I also do not like the fact that, with the change, signal is delivered from an rtld context. If taking such road, the fix would be to add __fillcontext2() to _rtld_init(), but I described the reason for other fix in the initial response. --rmx1G5GNWS01lHd9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSj6TtAAoJEJDCuSvBvK1BOSkQAIgX0yy3jpTylGEV1X5BfvRt SkbpN+JlzSgUTMKGrnA0qt03SQE2JZp9rHS+b8qPEgDuXG/P76pz10rqcMF+3wv3 4Xs9yiv0r4kRv9Blw7d5tvsXi1HH9sF8hPmj2TbL2rJ1qOv4hacg5LLvocyZZ4oz yyL5WRB6XwQTW3Ax8BXSMuxLvHA4P2PAQ6CxG2283O1WQrOHELroLGTeS1nCvjaI irefCxx5lXWS3HYi6NxkV6MWIBYI7e57tLZNAKJnF5FDT8bWw/0hqR1/8Jpp/80Y vEs/56f1yNzJibzTS84NmZ5iW5KsKC4NR/Oq3AyRgZQ65C6Du2oOyHgjDW7o6a+i JznvcXVGA4TlF0m2e0zoXAhG0uHtxKZaHeDm8MBrR2ghZY2w1o2IHxIW944yzzY4 wkHT3i2WsMVkpPqyIMr2Zb4Z/tKf9bnthk3K3+JnTbSJDnvpzU2xIU3B1iosmXM2 GRKBCwzD36MzJ0MBZWbSWtpdJZDcS+qZVyJviq3TKsqd0Tfbr+08LtkXJ8w+3gDV de4RMbNc9cqN9hq+mvvTxdZKUd4nFYuwZXx0qyUxZequ16tYpUfAXlnaVco6vYAS 5fFc1ztq+lVhjkLnGeW+SE1q4Alju6cgAnf25XUo+7W3ZEtC+DxXnrtuptpzcJ3X XZLeWMJ+5fuwTle9w9SP =pWVY -----END PGP SIGNATURE----- --rmx1G5GNWS01lHd9--