From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 14:38:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FA4216A4CE; Sun, 6 Jun 2004 14:38:30 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E286E43D1D; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6EF55FD03A; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51960-04; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DAB4DFD031; Sun, 6 Jun 2004 14:38:28 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086557908.52631.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 14:38:28 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: symbol binding on dlopen X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:38:30 -0000 I have been trying to formulate a reasonable explanation why I am seeing the following behavior: 1) start bash with nss_ldap. 2) nss_ldap pulls in libpthread.so.1 via. some non-direct dependency - libdb41.so.1. 3) Constructor is called for libpthread.so.1 that installs signal handler wrappers. 4) libreadline.so.4 uses sigaction, but it is not binding to the strong symbol of libpthread.so.1. It is still using the older one. Is this expected? Symbols will only be bound on the immediate dependencies of what is loaded by dlopen, or should all symbols within the closure be bound? Sean From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 14:52:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D9116A4CE; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC2643D4C; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 97416FD03A; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52133-04; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C7CD4FD031; Sun, 6 Jun 2004 14:52:45 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org In-Reply-To: <1086557908.52631.11.camel@server.mcneil.com> References: <1086557908.52631.11.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086558765.59346.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 14:52:45 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: symbol binding on dlopen X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:52:47 -0000 On Sun, 2004-06-06 at 14:38, Sean McNeil wrote: > I have been trying to formulate a reasonable explanation why I am seeing > the following behavior: > > 1) start bash with nss_ldap. > 2) nss_ldap pulls in libpthread.so.1 via. some non-direct dependency - > libdb41.so.1. > 3) Constructor is called for libpthread.so.1 that installs signal > handler wrappers. > 4) libreadline.so.4 uses sigaction, but it is not binding to the strong > symbol of libpthread.so.1. It is still using the older one. > > Is this expected? Symbols will only be bound on the immediate > dependencies of what is loaded by dlopen, or should all symbols within > the closure be bound? (Answering my own question partly) nsdispatch calls dlopen with RTLD_LOCAL. If I understand correctly, that would mean this is expected and that libraries outside of the DAG wouldn't be effected (/lib/readline.so.4). From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 16:28:45 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C89C16A4CE; Sun, 6 Jun 2004 16:28:44 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7645943D45; Sun, 6 Jun 2004 16:28:42 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 84714FD084; Sun, 6 Jun 2004 16:28:40 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00677-01; Sun, 6 Jun 2004 16:28:39 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 5B505FD052; Sun, 6 Jun 2004 16:28:39 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086564518.1123.17.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 16:28:39 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 23:28:45 -0000 I have another one that I can't explain. apache2 and libphp4. The php4 shared library that is pulled into apache2 has the following (with pthread mapped to libc_r): /usr/local/libexec/apache2/libphp4.so: libcrypt.so.2 => /lib/libcrypt.so.2 (0x200aed000) libmcal.so => /usr/local/lib/libmcal.so (0x200c07000) libc-client4.so.8 => /usr/local/lib/libc-client4.so.8 (0x200d18000) libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200ee2000) libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x20101c000) libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x201270000) libpq.so.3 => /usr/local/lib/libpq.so.3 (0x201393000) libmysqlclient.so.12 => /usr/local/lib/mysql/libmysqlclient.so.12 (0x2014b3000) libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x2015dc000) libmcrypt.so.8 => /usr/local/lib/libmcrypt.so.8 (0x2016f6000) libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0x20182f000) libldap.so.2 => /usr/local/lib/libldap.so.2 (0x201937000) liblber.so.2 => /usr/local/lib/liblber.so.2 (0x201a6f000) libpam.so.2 => /usr/lib/libpam.so.2 (0x201b7d000) libintl.so.6 => /usr/local/lib/libintl.so.6 (0x201c85000) libz.so.2 => /lib/libz.so.2 (0x201d8f000) libm.so.2 => /lib/libm.so.2 (0x201e9e000) libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x201fbf000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2021db000) libodbc.so.1 => /usr/local/lib/libodbc.so.1 (0x2023cb000) libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) libc.so.5 => /lib/libc.so.5 (0x20062a000) When I use the ldap account manager package (lam), it causes the httpd process to get stuck in a busy-loop eating 1/2 the cpu as: (gdb) bt #0 0x00000002014fcd4e in select () from /lib/libc.so.5 #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) at os-ip.c:733 #2 0x0000000200c34459 in wait4msg (ld=0x8c8c00, msgid=1, all=1, timeout=0x0, result=0x7fffffff9c38) at result.c:312 #3 0x0000000200c33fe7 in ldap_result (ld=0x8c8c00, msgid=1, all=1, timeout=0x0, result=0x7fffffff9c38) at result.c:113 #4 0x0000000200c376d4 in ldap_extended_operation_s (ld=0x8c8c00, reqoid=0x200c55134 "1.3.6.1.4.1.1466.20037", reqdata=0x0, sctrls=0x0, cctrls=0x0, retoidp=0x7fffffff9c90, retdatap=0x7fffffff9c98) at extended.c:138 #5 0x0000000200c4f606 in ldap_start_tls_s (ld=0x8c8c00, serverctrls=0x0, clientctrls=0x0) at tls.c:1725 #6 0x0000000203bf7a62 in ?? () from /usr/local/libexec/apache2/libphp4.so #7 0x0000000203cbfcd3 in ?? () from /usr/local/libexec/apache2/libphp4.so #8 0x0000000203cbfec9 in ?? () from /usr/local/libexec/apache2/libphp4.so #9 0x0000000203cb2a8a in ?? () from /usr/local/libexec/apache2/libphp4.so #10 0x0000000203c8cbee in ?? () from /usr/local/libexec/apache2/libphp4.so #11 0x0000000203cc4ca5 in ?? () from /usr/local/libexec/apache2/libphp4.so #12 0x00000000004222ea in ap_run_handler (r=0x7ba090) at config.c:151 #13 0x0000000000422860 in ap_invoke_handler (r=0x7ba090) at config.c:358 #14 0x000000000041f973 in ap_process_request (r=0x7ba090) at http_request.c:246 #15 0x000000000041b5bc in ap_process_http_connection (c=0x7b21b0) I do not understand why it is calling select in lib.so.5. Shouldn't it have called the one in libc_r? With GLOBAL or LOCAL DAG this should have been resolved via the weak symbol to __select, no? The interesting thing here is that if I use libpthread for apache then there are no problems. Maybe not all that suprising, though, as there is no real difference in the select with libpthread whereas libc_r has a much more complex implementation. Cheers, Sean From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 17:25:47 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81C416A4CE; Sun, 6 Jun 2004 17:25:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B8143D1F; Sun, 6 Jun 2004 17:25:47 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i570PktD023192; Sun, 6 Jun 2004 20:25:46 -0400 (EDT) Date: Sun, 6 Jun 2004 20:25:46 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086564518.1123.17.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:25:47 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > I have another one that I can't explain. apache2 and libphp4. > > The php4 shared library that is pulled into apache2 has the following > (with pthread mapped to libc_r): > > /usr/local/libexec/apache2/libphp4.so: [ ... ] > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > When I use the ldap account manager package (lam), it causes the httpd > process to get stuck in a busy-loop eating 1/2 the cpu as: > > (gdb) bt > #0 0x00000002014fcd4e in select () from /lib/libc.so.5 > #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) > at os-ip.c:733 > > I do not understand why it is calling select in lib.so.5. Shouldn't it > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > have been resolved via the weak symbol to __select, no? Yes, it shouldn't be using select() from libc; select() should be resolved to _select() in libc_r (which calls __sys_poll() in libc). > The interesting thing here is that if I use libpthread for apache then > there are no problems. Maybe not all that suprising, though, as there > is no real difference in the select with libpthread whereas libc_r has a > much more complex implementation. Sounds like the linker isn't doing the right thing. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 17:44:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D1316A4CE; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689A543D48; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CB594FD020; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00678-03; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9A0D3FD01A; Sun, 6 Jun 2004 17:44:11 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086569050.66929.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 17:44:11 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:44:13 -0000 On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > I have another one that I can't explain. apache2 and libphp4. > > > > The php4 shared library that is pulled into apache2 has the following > > (with pthread mapped to libc_r): > > > > /usr/local/libexec/apache2/libphp4.so: > [ ... ] > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > > > When I use the ldap account manager package (lam), it causes the httpd > > process to get stuck in a busy-loop eating 1/2 the cpu as: > > > > (gdb) bt > > #0 0x00000002014fcd4e in select () from /lib/libc.so.5 > > #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) > > at os-ip.c:733 > > > > I do not understand why it is calling select in lib.so.5. Shouldn't it > > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > > have been resolved via the weak symbol to __select, no? > > Yes, it shouldn't be using select() from libc; select() should be > resolved to _select() in libc_r (which calls __sys_poll() in libc). > > > The interesting thing here is that if I use libpthread for apache then > > there are no problems. Maybe not all that suprising, though, as there > > is no real difference in the select with libpthread whereas libc_r has a > > much more complex implementation. > > Sounds like the linker isn't doing the right thing. Would you think it is the linker, or rtld? Any ideas where I should start? I was going to look through rtld but I will focus on ld if you think that is where the problem is. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 03:52:56 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7DF016A4CE; Mon, 7 Jun 2004 03:52:56 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34C0443D1F; Sun, 6 Jun 2004 20:52:56 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i573qrtD010682; Sun, 6 Jun 2004 23:52:55 -0400 (EDT) Date: Sun, 6 Jun 2004 23:52:53 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086569050.66929.2.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 03:52:57 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > I do not understand why it is calling select in lib.so.5. Shouldn't it > > > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > > > have been resolved via the weak symbol to __select, no? > > > > Yes, it shouldn't be using select() from libc; select() should be > > resolved to _select() in libc_r (which calls __sys_poll() in libc). > > > > > The interesting thing here is that if I use libpthread for apache then > > > there are no problems. Maybe not all that suprising, though, as there > > > is no real difference in the select with libpthread whereas libc_r has a > > > much more complex implementation. > > > > Sounds like the linker isn't doing the right thing. > > Would you think it is the linker, or rtld? Any ideas where I should > start? I was going to look through rtld but I will focus on ld if you > think that is where the problem is. I meant the run-time linker (rtld). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 03:56:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ABF516A4CE; Mon, 7 Jun 2004 03:56:59 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241B843D45; Sun, 6 Jun 2004 20:56:59 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i573uwtD011570; Sun, 6 Jun 2004 23:56:58 -0400 (EDT) Date: Sun, 6 Jun 2004 23:56:58 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086569050.66929.2.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 03:56:59 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > I have another one that I can't explain. apache2 and libphp4. > > > > > > The php4 shared library that is pulled into apache2 has the following > > > (with pthread mapped to libc_r): > > > > > > /usr/local/libexec/apache2/libphp4.so: > > [ ... ] > > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > > libc.so.5 => /lib/libc.so.5 (0x20062a000) You really want to look at the executable (httpd?) too. What does 'ldd' on it show? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 04:06:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BFD416A4CE; Mon, 7 Jun 2004 04:06:30 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA0043D4C; Sun, 6 Jun 2004 21:06:28 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 9A7C2FD01A; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59142-03; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 1E534FD012; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086581186.59212.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 21:06:27 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:06:30 -0000 On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > > > I have another one that I can't explain. apache2 and libphp4. > > > > > > > > The php4 shared library that is pulled into apache2 has the following > > > > (with pthread mapped to libc_r): > > > > > > > > /usr/local/libexec/apache2/libphp4.so: > > > [ ... ] > > > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > > > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > You really want to look at the executable (httpd?) too. What > does 'ldd' on it show? Hmmm... /usr/local/sbin/httpd: libz.so.2 => /lib/libz.so.2 (0x200675000) libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 (0x200b12000) libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 (0x20114e000) libm.so.2 => /lib/libm.so.2 (0x201270000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) libc.so.5 => /lib/libc.so.5 (0x2014ab000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) So it looks like it is pulling in the ldap library without pthreads/libc_r first. So I think what is happening is that the symbols resolved with ldap aren't updated when it is part of the DAG of php4. Not sure why these would get resolved so early. I should think they are lazy and happen a lot later. But perhaps that is the bug? Are lazy resolutions failing to take into account the threading library needs from dlopen'ing php4? From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 04:37:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 448B116A4E2; Mon, 7 Jun 2004 04:37:44 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4E1D43D39; Mon, 7 Jun 2004 04:37:43 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i574bhtD020478; Mon, 7 Jun 2004 00:37:43 -0400 (EDT) Date: Mon, 7 Jun 2004 00:37:43 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086581186.59212.12.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:37:44 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > > You really want to look at the executable (httpd?) too. What > > does 'ldd' on it show? > > Hmmm... > > /usr/local/sbin/httpd: > libz.so.2 => /lib/libz.so.2 (0x200675000) > libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) > libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) > libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 > (0x200b12000) > libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) > liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) > libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) > libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) > libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 > (0x20114e000) > libm.so.2 => /lib/libm.so.2 (0x201270000) > libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) > libc.so.5 => /lib/libc.so.5 (0x2014ab000) > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) > > So it looks like it is pulling in the ldap library without > pthreads/libc_r first. So I think what is happening is that the symbols > resolved with ldap aren't updated when it is part of the DAG of php4. > Not sure why these would get resolved so early. I should think they are > lazy and happen a lot later. But perhaps that is the bug? Are lazy > resolutions failing to take into account the threading library needs > from dlopen'ing php4? Libc is the second library on the list, so any attempt to dlopen() a library that needs libc_r (or even libpthread) isn't going to work correctly. I think basically all your problems are the result of things being linked (ld) improperly. If the executable is going to dlopen() a library that requires the threads library, then the executable must explicitly link to the threads libary. I said before, if you set CFLAGS=-pthread, it will avoid linking to libpthread when building shared libraries. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 04:59:35 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC4E16A4CE; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4157F43D46; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 98B6AFD03B; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59128-07; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DE74BFD020; Sun, 6 Jun 2004 21:59:29 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086584369.7335.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 21:59:29 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:59:35 -0000 On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > > > You really want to look at the executable (httpd?) too. What > > > does 'ldd' on it show? > > > > Hmmm... > > > > /usr/local/sbin/httpd: > > libz.so.2 => /lib/libz.so.2 (0x200675000) > > libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) > > libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) > > libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 > > (0x200b12000) > > libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) > > liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) > > libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) > > libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) > > libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 > > (0x20114e000) > > libm.so.2 => /lib/libm.so.2 (0x201270000) > > libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) > > libc.so.5 => /lib/libc.so.5 (0x2014ab000) > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) > > > > So it looks like it is pulling in the ldap library without > > pthreads/libc_r first. So I think what is happening is that the symbols > > resolved with ldap aren't updated when it is part of the DAG of php4. > > Not sure why these would get resolved so early. I should think they are > > lazy and happen a lot later. But perhaps that is the bug? Are lazy > > resolutions failing to take into account the threading library needs > > from dlopen'ing php4? > > Libc is the second library on the list, so any attempt to dlopen() > a library that needs libc_r (or even libpthread) isn't going to > work correctly. > > I think basically all your problems are the result of things > being linked (ld) improperly. If the executable is going to > dlopen() a library that requires the threads library, then > the executable must explicitly link to the threads libary. > I said before, if you set CFLAGS=-pthread, it will avoid > linking to libpthread when building shared libraries. That is very interesting. This works perfectly for i386 and always has. There is a fundamental difference here that is going to cause all sorts of issues with ports and programs. Essentially, there is no reason why this should not work. It works for Linux, it works for FreeBSD/x86, why not FreeBSD/amd64? You may be 10000% correct in principle, I don't know. I personally think that this should not be the case. Anyone should be able to create loadable extensions to a program that may do threading of some sort and not require the starting application to be linked with the thread library. Principle is all well and good, but we why enforce something that doesn't need to be? Why can't freebsd/amd64 behave nice like freebsd/i386. Let me make reiterate.... I am using a system that I converted from i386 to amd64. Everything (all the ports) were working without any problems whatsoever. These are the same exact ports that I convert over to amd64. If it is not legal to do things like this then why do these exact same ports work perfectly fine with freebsd/i386? Your analysis and assistance with this has been invaluable so far, but I don't want this to just be dismissed because in principle it doesn't need to be supported. IMHO, amd64 should work just like i386. Since it works with i386, shouldn't we make it work for amd64? Sean From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 05:30:55 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 492FB16A4CE; Mon, 7 Jun 2004 05:30:55 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF48B43D2D; Mon, 7 Jun 2004 05:30:54 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i575UrtD001611; Mon, 7 Jun 2004 01:30:53 -0400 (EDT) Date: Mon, 7 Jun 2004 01:30:53 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086584369.7335.11.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:30:55 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > > > > Libc is the second library on the list, so any attempt to dlopen() > > a library that needs libc_r (or even libpthread) isn't going to > > work correctly. > > > > I think basically all your problems are the result of things > > being linked (ld) improperly. If the executable is going to > > dlopen() a library that requires the threads library, then > > the executable must explicitly link to the threads libary. > > I said before, if you set CFLAGS=-pthread, it will avoid > > linking to libpthread when building shared libraries. > > That is very interesting. This works perfectly for i386 and always > has. There is a fundamental difference here that is going to cause all > sorts of issues with ports and programs. Essentially, there is no > reason why this should not work. It works for Linux, it works for > FreeBSD/x86, why not FreeBSD/amd64? Show me the same exact shared library dependencies under x86. > You may be 10000% correct in principle, I don't know. I personally > think that this should not be the case. Anyone should be able to create > loadable extensions to a program that may do threading of some sort and > not require the starting application to be linked with the thread > library. Principle is all well and good, but we why enforce something > that doesn't need to be? Why can't freebsd/amd64 behave nice like > freebsd/i386. It doesn't work under i386 either. Remember the nss_ldap problem? That was exactly the same and on i386. > Let me make reiterate.... I am using a system that I converted from > i386 to amd64. Everything (all the ports) were working without any > problems whatsoever. These are the same exact ports that I convert over > to amd64. If it is not legal to do things like this then why do these > exact same ports work perfectly fine with freebsd/i386? > > Your analysis and assistance with this has been invaluable so far, but I > don't want this to just be dismissed because in principle it doesn't > need to be supported. IMHO, amd64 should work just like i386. Since it > works with i386, shouldn't we make it work for amd64? There is no difference. It isn't going to work on i386 either. Once you load the threads library, the libc locking functions will be overloaded with the locking functions in libpthread. When libpthread is unloaded, libc locking functions still point to the now non-existent library. If something tries to use a lock, fall down go boom. There's also the problem of overloaded functions and cancellation points. These won't work correctly because of ordering. It's like trying to use '-lc -lpthread' to link an application. That isn't going to work; you need '-lpthread -lc'. There are two reasons for a library to use the threads library. a) It uses threading functions for thread safety; or b) It creates threads behind the scenes (for instance if there were a libaio). For a), it needn't link to the threads library because all the necessary locking functions are in libc. If an application is threaded, then the threads library will be pulled in (along with the locking functions) because the _application_ will be linked to the threads library. For b), we mandate that the application always be linked with the threads library because the library needs threads. This should be solved by fixing the ports appropriately. For a), it can be done by using PTHREAD_LIBS=-pthread. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 10:18:32 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D74416A4CE; Mon, 7 Jun 2004 10:18:32 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4890F43D5D; Mon, 7 Jun 2004 10:18:30 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CBA1DFD03B; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08046-07; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 22129FD020; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086603496.7335.29.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 03:18:17 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:18:32 -0000 On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > > > > > > Libc is the second library on the list, so any attempt to dlopen() > > > a library that needs libc_r (or even libpthread) isn't going to > > > work correctly. > > > > > > I think basically all your problems are the result of things > > > being linked (ld) improperly. If the executable is going to > > > dlopen() a library that requires the threads library, then > > > the executable must explicitly link to the threads libary. > > > I said before, if you set CFLAGS=-pthread, it will avoid > > > linking to libpthread when building shared libraries. > > > > That is very interesting. This works perfectly for i386 and always > > has. There is a fundamental difference here that is going to cause all > > sorts of issues with ports and programs. Essentially, there is no > > reason why this should not work. It works for Linux, it works for > > FreeBSD/x86, why not FreeBSD/amd64? > > Show me the same exact shared library dependencies under x86. I'm sorry, but I have rebuilt everything on this machine from i386 to amd64 so I do not have the older binaries to show the same dependency. Unless something odd happened between the following: 1) working i386. 2) build world build/install kernel with a target arch amd64 3) cp ld-elf.so.1 to ld-elf32.so.1, reboot, install world 4) portupgrade -af then the dependencies should be identical between i386 and amd64. > > You may be 10000% correct in principle, I don't know. I personally > > think that this should not be the case. Anyone should be able to create > > loadable extensions to a program that may do threading of some sort and > > not require the starting application to be linked with the thread > > library. Principle is all well and good, but we why enforce something > > that doesn't need to be? Why can't freebsd/amd64 behave nice like > > freebsd/i386. > > It doesn't work under i386 either. Remember the nss_ldap > problem? That was exactly the same and on i386. There is no nss_ldap problem. nss_ldap worked perfectly on i386. It causes issues on amd64 because of a problem in threads. > > Let me make reiterate.... I am using a system that I converted from > > i386 to amd64. Everything (all the ports) were working without any > > problems whatsoever. These are the same exact ports that I convert over > > to amd64. If it is not legal to do things like this then why do these > > exact same ports work perfectly fine with freebsd/i386? > > > > Your analysis and assistance with this has been invaluable so far, but I > > don't want this to just be dismissed because in principle it doesn't > > need to be supported. IMHO, amd64 should work just like i386. Since it > > works with i386, shouldn't we make it work for amd64? > > There is no difference. It isn't going to work on i386 either. > Once you load the threads library, the libc locking functions > will be overloaded with the locking functions in libpthread. > When libpthread is unloaded, libc locking functions still point > to the now non-existent library. If something tries to use > a lock, fall down go boom. It worked on i386. None of the cases mentioned before unload the thread library until an atexit. > There's also the problem of overloaded functions and cancellation > points. These won't work correctly because of ordering. It's > like trying to use '-lc -lpthread' to link an application. > That isn't going to work; you need '-lpthread -lc'. As far as I know, this works. At least for Linux and it should for FreeBSD. The ordering doesn't matter because the overloaded routines are actually weak references in libc and strong references in pthread. So pthread symbols win. > There are two reasons for a library to use the threads library. > > a) It uses threading functions for thread safety; or > b) It creates threads behind the scenes (for instance > if there were a libaio). > > For a), it needn't link to the threads library because all > the necessary locking functions are in libc. If an application > is threaded, then the threads library will be pulled in (along > with the locking functions) because the _application_ will > be linked to the threads library. For b), we mandate that > the application always be linked with the threads library > because the library needs threads. So I think we agree that thread-safe libraries should not link with -lpthread if they do not call thread-specific routines. > This should be solved by fixing the ports appropriately. > For a), it can be done by using PTHREAD_LIBS=-pthread. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 11:02:08 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7B0516A4D3 for ; Mon, 7 Jun 2004 11:02:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9590443D53 for ; Mon, 7 Jun 2004 11:02:08 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i57B26rQ043555 for ; Mon, 7 Jun 2004 11:02:06 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i57B26HX043549 for freebsd-threads@freebsd.org; Mon, 7 Jun 2004 11:02:06 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Jun 2004 11:02:06 GMT Message-Id: <200406071102.i57B26HX043549@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:02:08 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork 3 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/20] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/08] bin/51949 threads thread in accept cannot be cancelled 14 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 13:25:35 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A01F316A4CE; Mon, 7 Jun 2004 13:25:35 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C04C43D1F; Mon, 7 Jun 2004 13:25:35 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57DPVtD010958; Mon, 7 Jun 2004 09:25:33 -0400 (EDT) Date: Mon, 7 Jun 2004 09:25:31 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086603496.7335.29.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 13:25:35 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > > > > It doesn't work under i386 either. Remember the nss_ldap > > problem? That was exactly the same and on i386. > > There is no nss_ldap problem. nss_ldap worked perfectly on i386. It > causes issues on amd64 because of a problem in threads. Yes, there was. See the archives (I forget if it was -current or -threads). I believe the resolver functions in libc were changed to work around it. > > > Let me make reiterate.... I am using a system that I converted from > > > i386 to amd64. Everything (all the ports) were working without any > > > problems whatsoever. These are the same exact ports that I convert over > > > to amd64. If it is not legal to do things like this then why do these > > > exact same ports work perfectly fine with freebsd/i386? > > > > > > Your analysis and assistance with this has been invaluable so far, but I > > > don't want this to just be dismissed because in principle it doesn't > > > need to be supported. IMHO, amd64 should work just like i386. Since it > > > works with i386, shouldn't we make it work for amd64? > > > > There is no difference. It isn't going to work on i386 either. > > Once you load the threads library, the libc locking functions > > will be overloaded with the locking functions in libpthread. > > When libpthread is unloaded, libc locking functions still point > > to the now non-existent library. If something tries to use > > a lock, fall down go boom. > > It worked on i386. None of the cases mentioned before unload the thread > library until an atexit. I thought they were automatically unloaded when the library was unloaded. That was the problem with nss_ldap. > > There's also the problem of overloaded functions and cancellation > > points. These won't work correctly because of ordering. It's > > like trying to use '-lc -lpthread' to link an application. > > That isn't going to work; you need '-lpthread -lc'. > > As far as I know, this works. At least for Linux and it should for > FreeBSD. The ordering doesn't matter because the overloaded routines > are actually weak references in libc and strong references in pthread. > So pthread symbols win. It doesn't work here and I don't believe ever has since libc_r was split from libc. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 16:21:49 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77AFE16A4CE; Mon, 7 Jun 2004 16:21:49 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B54643D5E; Mon, 7 Jun 2004 16:21:47 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id C4DFBFD03B; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09857-04; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 21E2BFD020; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086625305.10454.33.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 09:21:45 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:21:49 -0000 On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > > > > > > It doesn't work under i386 either. Remember the nss_ldap > > > problem? That was exactly the same and on i386. > > > > There is no nss_ldap problem. nss_ldap worked perfectly on i386. It > > causes issues on amd64 because of a problem in threads. > > Yes, there was. See the archives (I forget if it was -current > or -threads). I believe the resolver functions in libc were > changed to work around it. If you are talking about nsdispatch, then I am very intimate with the issue as I found and fixed the problem. It has to do with when an application finally shuts down. That is when it unloaded the library. > > > > Let me make reiterate.... I am using a system that I converted from > > > > i386 to amd64. Everything (all the ports) were working without any > > > > problems whatsoever. These are the same exact ports that I convert over > > > > to amd64. If it is not legal to do things like this then why do these > > > > exact same ports work perfectly fine with freebsd/i386? > > > > > > > > Your analysis and assistance with this has been invaluable so far, but I > > > > don't want this to just be dismissed because in principle it doesn't > > > > need to be supported. IMHO, amd64 should work just like i386. Since it > > > > works with i386, shouldn't we make it work for amd64? > > > > > > There is no difference. It isn't going to work on i386 either. > > > Once you load the threads library, the libc locking functions > > > will be overloaded with the locking functions in libpthread. > > > When libpthread is unloaded, libc locking functions still point > > > to the now non-existent library. If something tries to use > > > a lock, fall down go boom. > > > > It worked on i386. None of the cases mentioned before unload the thread > > library until an atexit. > > I thought they were automatically unloaded when the library > was unloaded. That was the problem with nss_ldap. During the life of any application, it usually loads extensions but doesn't unload them unless shutting down. bash was never unloading the nss_ldap, httpd was never unloading php4. This is not the issue (load/unload). > > > There's also the problem of overloaded functions and cancellation > > > points. These won't work correctly because of ordering. It's > > > like trying to use '-lc -lpthread' to link an application. > > > That isn't going to work; you need '-lpthread -lc'. > > > > As far as I know, this works. At least for Linux and it should for > > FreeBSD. The ordering doesn't matter because the overloaded routines > > are actually weak references in libc and strong references in pthread. > > So pthread symbols win. > > It doesn't work here and I don't believe ever has since libc_r > was split from libc. Many years ago, I was involved with pthreads for Linux. I helped them get things straight using the weak reference trick. I don't remember where I picked it up from, but I it was real slick how they were used to override functions in libc by having stronger references in the threading lib. libc_r and folks don't use this trick anymore? Odd. But the questions for today: Say you have an application that depends on libraries A, B, C, and libc. It then uses dlopen to load D. D depends on E, F, libpthread, and B. Is B considered to be in D's DAG? If so, then when a function within B calls a function that hasn't been bound yet in libpthread then it should bind to the threaded version. There are good arguments either way. IMHO, rtld is acting as though the answer is no and I want it to behave as yes. There is strong evidence to support this. The libreadline trace from bash and the php4 trace from httpd both only make sense if the lazy symbol resolver is not ending up with the threaded version of some call (sigaction and select respectively). Second, to save me some time can someone outline the symbol name mechanism used by libpthread? Here is what I expect: libc provides a sigaction function through a weak reference that points to some internal name (like __sigaction). libpthread provides a strong reference to sigaction thus, when loaded, overrides usage of sigaction. This should happen irregardless of whether libpthread is in the DAG for the caller (IMHO), but I'm sure there are other opinions. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 16:50:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED67D16A4CE; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A742C43D1F; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57GoxtD000256; Mon, 7 Jun 2004 12:50:59 -0400 (EDT) Date: Mon, 7 Jun 2004 12:50:59 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086625305.10454.33.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:51:00 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > > > > It doesn't work here and I don't believe ever has since libc_r > > was split from libc. > > Many years ago, I was involved with pthreads for Linux. I helped them > get things straight using the weak reference trick. I don't remember > where I picked it up from, but I it was real slick how they were used to > override functions in libc by having stronger references in the > threading lib. libc_r and folks don't use this trick anymore? Odd. > > But the questions for today: > > Say you have an application that depends on libraries A, B, C, and > libc. It then uses dlopen to load D. D depends on E, F, libpthread, > and B. Is B considered to be in D's DAG? > > If so, then when a function within B calls a function that hasn't been > bound yet in libpthread then it should bind to the threaded version. > There are good arguments either way. IMHO, rtld is acting as though the > answer is no and I want it to behave as yes. I don't know what a DAG is, but I believe I've already explained the problem. We don't litter our thread libraries with strong references for every thread interface. You must make sure references are resolved correctly by linking ordering. > There is strong evidence to support this. The libreadline trace from > bash and the php4 trace from httpd both only make sense if the lazy > symbol resolver is not ending up with the threaded version of some call > (sigaction and select respectively). > > Second, to save me some time can someone outline the symbol name > mechanism used by libpthread? Here is what I expect: > > libc provides a sigaction function through a weak reference that points > to some internal name (like __sigaction). libpthread provides a strong > reference to sigaction thus, when loaded, overrides usage of sigaction. > This should happen irregardless of whether libpthread is in the DAG for > the caller (IMHO), but I'm sure there are other opinions. There are no strong references (other than a handful that are needed by rtld). We mandate that you link things in the proper order. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 17:02:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6554916A4CE; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2677343D58; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CF4EAFD03B; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09857-06; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0F114FD020; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086627777.39706.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 10:02:57 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:02:59 -0000 On Mon, 2004-06-07 at 09:50, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > > > > > > It doesn't work here and I don't believe ever has since libc_r > > > was split from libc. > > > > Many years ago, I was involved with pthreads for Linux. I helped them > > get things straight using the weak reference trick. I don't remember > > where I picked it up from, but I it was real slick how they were used to > > override functions in libc by having stronger references in the > > threading lib. libc_r and folks don't use this trick anymore? Odd. > > > > But the questions for today: > > > > Say you have an application that depends on libraries A, B, C, and > > libc. It then uses dlopen to load D. D depends on E, F, libpthread, > > and B. Is B considered to be in D's DAG? > > > > If so, then when a function within B calls a function that hasn't been > > bound yet in libpthread then it should bind to the threaded version. > > There are good arguments either way. IMHO, rtld is acting as though the > > answer is no and I want it to behave as yes. > > I don't know what a DAG is, but I believe I've already explained > the problem. We don't litter our thread libraries with strong > references for every thread interface. You must make sure > references are resolved correctly by linking ordering. > > > There is strong evidence to support this. The libreadline trace from > > bash and the php4 trace from httpd both only make sense if the lazy > > symbol resolver is not ending up with the threaded version of some call > > (sigaction and select respectively). > > > > Second, to save me some time can someone outline the symbol name > > mechanism used by libpthread? Here is what I expect: > > > > libc provides a sigaction function through a weak reference that points > > to some internal name (like __sigaction). libpthread provides a strong > > reference to sigaction thus, when loaded, overrides usage of sigaction. > > This should happen irregardless of whether libpthread is in the DAG for > > the caller (IMHO), but I'm sure there are other opinions. > > There are no strong references (other than a handful that are > needed by rtld). We mandate that you link things in the proper > order. Then I submit to you that signals are broken in KSE/libpthread at the very least. libpthread makes the assumption that it will take over principle control of sigaction and friends. So, if I link with "-lc -lpthread" I should use the versions in libc and it should work. If I link with "-lpthread -lc" then I should use the versions in libpthread. Yet constructors for libpthread will install hooks for signals that undermines the proper behavior of the original sigaction function. I also submit to you that FreeBSD is not behaving like any other UNIX implementation that I have worked with if this is the case. pthread functions should have precedence over their libc counterparts regardless of link order. From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 21:49:10 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F14E16A4CE; Mon, 7 Jun 2004 21:49:10 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABF243D46; Mon, 7 Jun 2004 21:49:09 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.200.253) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002D5EE6; Tue, 8 Jun 2004 07:49:08 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 4517241D3; Tue, 8 Jun 2004 07:50:54 +1000 (EST) Date: Tue, 8 Jun 2004 07:50:54 +1000 From: Tim Robbins To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Message-ID: <20040607215054.GA41798@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [tjr@FreeBSD.org: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:49:10 -0000 Anyone who has resorted to using libc_r instead of libpthread on amd64 should update their sources (ensuring they get context.S revision 1.6), rebuild and reinstall libpthread (or world), then give it another try. The bug I just fixed looks to have been responsible for the mysterious crashes I was seeing in Mozilla/Firefox, XMMS and GNOME. Tim ----- Forwarded message from "Tim J. Robbins" ----- From: "Tim J. Robbins" Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S X-FreeBSD-CVS-Branch: HEAD Precedence: bulk X-Loop: FreeBSD.ORG X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 tjr 2004-06-07 21:25:16 UTC FreeBSD src repository Modified files: lib/libpthread/arch/amd64/amd64 context.S Log: Avoid clobbering the red zone when running on the new context's stack in _amd64_restore_context(). Revision Changes Path 1.6 +5 -0 src/lib/libpthread/arch/amd64/amd64/context.S ----- End forwarded message ----- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 01:07:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 321B616A4E8; Tue, 8 Jun 2004 01:07:59 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B63D43D49; Tue, 8 Jun 2004 01:07:55 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M22V47LA; Tue, 8 Jun 2004 09:07:51 +0800 Message-ID: <40C51203.8050508@freebsd.org> Date: Tue, 08 Jun 2004 09:10:27 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Robbins References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> In-Reply-To: <20040607215054.GA41798@cat.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit:src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:07:59 -0000 Is there any reason to use memory indirect jump ? did you have benchmarked context switch speed before and after this commit ? I won't use such indirect jump in speed sensitive case, it is not CPU branch trace cache friendly, it is better to use ret to match call in up level. David Xu Tim Robbins wrote: > Anyone who has resorted to using libc_r instead of libpthread on amd64 > should update their sources (ensuring they get context.S revision 1.6), > rebuild and reinstall libpthread (or world), then give it another try. > The bug I just fixed looks to have been responsible for the mysterious > crashes I was seeing in Mozilla/Firefox, XMMS and GNOME. > > > Tim > > ----- Forwarded message from "Tim J. Robbins" ----- > > From: "Tim J. Robbins" > Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > cvs-all@FreeBSD.org > Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S > X-FreeBSD-CVS-Branch: HEAD > Precedence: bulk > X-Loop: FreeBSD.ORG > X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 > > tjr 2004-06-07 21:25:16 UTC > > FreeBSD src repository > > Modified files: > lib/libpthread/arch/amd64/amd64 context.S > Log: > Avoid clobbering the red zone when running on the new context's stack in > _amd64_restore_context(). > > Revision Changes Path > 1.6 +5 -0 src/lib/libpthread/arch/amd64/amd64/context.S > > ----- End forwarded message ----- > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 01:10:23 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD2EB16A4CE; Tue, 8 Jun 2004 01:10:23 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81DF743D4C; Tue, 8 Jun 2004 01:10:23 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 7012D8826; Mon, 7 Jun 2004 18:10:23 -0700 (PDT) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Mon, 7 Jun 2004 18:10:22 -0700 User-Agent: KMail/1.6.1 References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> <40C51203.8050508@freebsd.org> In-Reply-To: <40C51203.8050508@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406071810.23069.peter@wemm.org> cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit:src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:10:23 -0000 On Monday 07 June 2004 06:10 pm, David Xu wrote: > Is there any reason to use memory indirect jump ? did you > have benchmarked context switch speed before and after this commit ? > I won't use such indirect jump in speed sensitive case, it is > not CPU branch trace cache friendly, it is better to use > ret to match call in up level. Because the return address is already on the higher level stack frame, and copying it (read/write/ret) is more awkward than the read+indirect jump. Unfortunately, we can't indirectly access the flags register. > David Xu > > Tim Robbins wrote: > > Anyone who has resorted to using libc_r instead of libpthread on > > amd64 should update their sources (ensuring they get context.S > > revision 1.6), rebuild and reinstall libpthread (or world), then > > give it another try. The bug I just fixed looks to have been > > responsible for the mysterious crashes I was seeing in > > Mozilla/Firefox, XMMS and GNOME. > > > > > > Tim > > > > ----- Forwarded message from "Tim J. Robbins" > > ----- > > > > From: "Tim J. Robbins" > > Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) > > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > > cvs-all@FreeBSD.org > > Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S > > X-FreeBSD-CVS-Branch: HEAD > > Precedence: bulk > > X-Loop: FreeBSD.ORG > > X-Bogosity: No, tests=bogofilter, spamicity=0.000000, > > version=0.15.7 > > > > tjr 2004-06-07 21:25:16 UTC > > > > FreeBSD src repository > > > > Modified files: > > lib/libpthread/arch/amd64/amd64 context.S > > Log: > > Avoid clobbering the red zone when running on the new context's > > stack in _amd64_restore_context(). > > > > Revision Changes Path > > 1.6 +5 -0 > > src/lib/libpthread/arch/amd64/amd64/context.S > > > > ----- End forwarded message ----- > > _______________________________________________ > > freebsd-threads@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to > > "freebsd-threads-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 01:15:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E20A16A4CE; Tue, 8 Jun 2004 01:15:15 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 164CE43D2D; Tue, 8 Jun 2004 01:15:13 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M22V47MS; Tue, 8 Jun 2004 09:15:05 +0800 Message-ID: <40C513B5.8070406@freebsd.org> Date: Tue, 08 Jun 2004 09:17:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <200406071810.23069.peter@wemm.org> In-Reply-To: <200406071810.23069.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvscommit:src/lib/libpthread/arch/amd64/amd 64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:15:15 -0000 Peter Wemm wrote: > On Monday 07 June 2004 06:10 pm, David Xu wrote: > >>Is there any reason to use memory indirect jump ? did you >>have benchmarked context switch speed before and after this commit ? >>I won't use such indirect jump in speed sensitive case, it is >>not CPU branch trace cache friendly, it is better to use >>ret to match call in up level. > > > Because the return address is already on the higher level stack frame, > and copying it (read/write/ret) is more awkward than the read+indirect > jump. Unfortunately, we can't indirectly access the flags register. > I would like someone to test it: http://people.freebsd.org/~davidxu/kse/test/ctxswitch.c tell me the result before and after this commit. > >>David Xu >> >>Tim Robbins wrote: >> >>>Anyone who has resorted to using libc_r instead of libpthread on >>>amd64 should update their sources (ensuring they get context.S >>>revision 1.6), rebuild and reinstall libpthread (or world), then >>>give it another try. The bug I just fixed looks to have been >>>responsible for the mysterious crashes I was seeing in >>>Mozilla/Firefox, XMMS and GNOME. >>> >>> >>>Tim >>> >>>----- Forwarded message from "Tim J. Robbins" >>>----- >>> >>>From: "Tim J. Robbins" >>>Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) >>>To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, >>> cvs-all@FreeBSD.org >>>Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S >>>X-FreeBSD-CVS-Branch: HEAD >>>Precedence: bulk >>>X-Loop: FreeBSD.ORG >>>X-Bogosity: No, tests=bogofilter, spamicity=0.000000, >>>version=0.15.7 >>> >>>tjr 2004-06-07 21:25:16 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> lib/libpthread/arch/amd64/amd64 context.S >>> Log: >>> Avoid clobbering the red zone when running on the new context's >>>stack in _amd64_restore_context(). >>> >>> Revision Changes Path >>> 1.6 +5 -0 >>>src/lib/libpthread/arch/amd64/amd64/context.S >>> >>>----- End forwarded message ----- >>>_______________________________________________ >>>freebsd-threads@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-threads >>>To unsubscribe, send any mail to >>>"freebsd-threads-unsubscribe@freebsd.org" >> >>_______________________________________________ >>freebsd-amd64@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >>To unsubscribe, send any mail to >>"freebsd-amd64-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 01:44:01 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D7E616A4CE; Tue, 8 Jun 2004 01:44:01 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id F27ED43D1D; Tue, 8 Jun 2004 01:43:58 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.200.253) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002E51BD; Tue, 8 Jun 2004 11:43:57 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 8320B41D0; Tue, 8 Jun 2004 11:45:44 +1000 (EST) Date: Tue, 8 Jun 2004 11:45:44 +1000 From: Tim Robbins To: David Xu Message-ID: <20040608014544.GA43197@cat.robbins.dropbear.id.au> References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> <40C51203.8050508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C51203.8050508@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:44:01 -0000 On Tue, Jun 08, 2004 at 09:10:27AM +0800, David Xu wrote: > Is there any reason to use memory indirect jump ? did you > have benchmarked context switch speed before and after this commit ? > I won't use such indirect jump in speed sensitive case, it is > not CPU branch trace cache friendly, it is better to use > ret to match call in up level. For the reason Peter mentioned, we can't use "ret" in the general case. It may be possible to do it that way for voluntary/synchronous context switches, but it's probably not worth the effort -- even the i386 context switch functions have not been micro-optimised to this level: they save scratch registers + flags, perform redundant null pointer checks, validate mc_len, initialise and save the FPU control word for threads that don't touch the FPU, perform unaligned jumps, etc. etc. As for benchmarks: the new version runs Mozilla infinitely faster :-) Tim From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 02:07:55 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85AD16A4CE; Tue, 8 Jun 2004 02:07:55 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D1F43D54; Tue, 8 Jun 2004 02:07:55 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.174) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002E6DC6; Tue, 8 Jun 2004 12:07:53 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id CD72341D0; Tue, 8 Jun 2004 12:09:40 +1000 (EST) Date: Tue, 8 Jun 2004 12:09:40 +1000 From: Tim Robbins To: David Xu Message-ID: <20040608020940.GB43197@cat.robbins.dropbear.id.au> References: <200406071810.23069.peter@wemm.org> <40C513B5.8070406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C513B5.8070406@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvscommit:src/lib/libpthread/arch/amd64/amd 64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:07:55 -0000 On Tue, Jun 08, 2004 at 09:17:41AM +0800, David Xu wrote: > Peter Wemm wrote: > > >On Monday 07 June 2004 06:10 pm, David Xu wrote: > > > >>Is there any reason to use memory indirect jump ? did you > >>have benchmarked context switch speed before and after this commit ? > >>I won't use such indirect jump in speed sensitive case, it is > >>not CPU branch trace cache friendly, it is better to use > >>ret to match call in up level. > > > > > >Because the return address is already on the higher level stack frame, > >and copying it (read/write/ret) is more awkward than the read+indirect > >jump. Unfortunately, we can't indirectly access the flags register. > > > I would like someone to test it: > http://people.freebsd.org/~davidxu/kse/test/ctxswitch.c > tell me the result before and after this commit. System: AMD Athlon 64 3000+, ASUS K8V, FreeBSD 5.2-tjr_perf with kernel config tuned for performance (no INVARIANTS, no WITNESS), multiuser mode, XFree86 + GNOME running. Test program compiled with gcc -O2 -pthread -static. ctxold = old (broken) code using ret ctxnew = new correct code using indirect jump ctxopt = same as ctxnew but does not save scratch registers or flags, redundant checks removed, jumps aligned to dword boundary $ time ./ctxold; time ./ctxnew; time ./ctxopt testing scope process context switch speed... context switches:1779631/s testing scope system context switch speed... context switches:386696/s 21.01s real 10.40s user 9.49s system testing scope process context switch speed... context switches:1823471/s testing scope system context switch speed... context switches:383949/s 21.00s real 10.34s user 9.55s system testing scope process context switch speed... context switches:1864775/s testing scope system context switch speed... context switches:386127/s 21.01s real 10.42s user 9.48s system Tim From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 02:57:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D31516A4CE; Tue, 8 Jun 2004 02:57:42 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0164A43D4C; Tue, 8 Jun 2004 02:57:39 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 401CBFD06C; Mon, 7 Jun 2004 19:57:38 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-03; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0B19DFD03A; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org, freebsd-current@freebsd.org, freebsd-gnome@freebsd.org Content-Type: text/plain Message-Id: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 19:57:35 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:57:42 -0000 Up front, I'd like to make a few apologies: 1) I am sorry for the length of this email. 2) Although some very valid opinions have been expressed, I respectfully have to disagree. This email will hopefully strengthen my position. The problem: (If you just want kse threads to work for you properly, just apply the patch at the end of this email and try it out). kse threads on amd64 doesn't work with gnome. It crashes applications here and there. gnome-terminal is essentially unusable. I strongly believe this to be a binding issue. I've examined rtld and I'm satisfied that it is behaving appropriately, so I took a long hard look at how FreeBSD has implemented the pthread interface, how it is being used, and how people expect it to behave. FreeBSD pthread interface: I have no idea why, but on FreeBSD all the pthread functions are weak symbols. I have not beed given a very satisfactory answer though I have tried to understand and continue to look for enlightenment. To me, this means that there is no authorative answer to "who is the primary provider" of the weak symbols in libc. It is instead the first occurrence of the weak symbol that takes precedence. This means that if the program itself doesn't link with the pthread library yet some other library uses it then you are pretty much hosed. I've seen just this happen with plenty of gnome applications. It also means that there is an ordering dependency that I'm not sure is reasonable to enforce. Other pthread interfaces: I don't know what Linux does now, but when we first built pthreads for Linux we made the pthread library symbols definitive. They always were the overriding authority. It was modelled after what I saw in Solaris. So, taking select as an example, libc.so - internal select called something else with a weak reference to used symbol. libpthread.so - select essentially provided directly in the library or is a strong reference to an internal version. i.e. libc weak, libpthread strong. This allows for any ordering of libraries during linking. Very good (IMHO) and has other benifits as well - like security. Application issues: As mentioned above, gnome is not very usable as things stand. I had to move to libc_r to get any stability at all. Besides gnome, I have found issues with apache2/php4, wine, and bash with nss_ldap to name a few. Security: Actually, having an authorative provider of core libc functions would be very helpful to eliminating a potential security risk. An application that is linked with libpthread wouldn't be able to dlopen some other library that could potentially take over libc weak functionality. Additionally, some sort of non-threaded library could be created that blocked a program from overriding libc routines with thread versions whenever it was linked directly to the main application. Proof is in the pudding: What can I say? Some people will insist that the gnome applications are broken somehow or that what I'm saying doesn't conform to their view as how the thread libraries should work. I admit I do not fully understand the dogma behind making them all weak symbols, but so far nothing I've heard trumps the fact that doing this makes everything work. Since applying the patch below, my amd64 system has worked flawlessly with gnome and libpthread.so.1. It has not shown any of the problems that have been haunting me since I switched over from running in i386 mode. The patch: A patch to apply in /usr/src/lib/libpthread is included at the end of this email. I haven't bothered doing it for libc_r even though it should be done. Apache2/php4 would have issues, for instance, with libc_r without making the symbols strong references. Anyone else that wants to use gnome right now under amd64 might want to try out this patch. Cheers, Sean diff -c3pr thread.orig/thr_accept.c thread/thr_accept.c *** thread.orig/thr_accept.c Tue Dec 9 15:40:27 2003 --- thread/thr_accept.c Mon Jun 7 17:48:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__accept, accept); - int __accept(int s, struct sockaddr *addr, socklen_t *addrlen) { --- 32,37 ---- *************** __accept(int s, struct sockaddr *addr, s *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__accept, accept); diff -c3pr thread.orig/thr_aio_suspend.c thread/thr_aio_suspend.c *** thread.orig/thr_aio_suspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_aio_suspend.c Mon Jun 7 17:49:10 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_aio_suspend, aio_suspend); - int _aio_suspend(const struct aiocb * const iocbs[], int niocb, const struct timespec *timeout) --- 33,38 ---- *************** _aio_suspend(const struct aiocb * const *** 49,51 **** --- 47,50 ---- return (ret); } + __strong_reference(_aio_suspend, aio_suspend); diff -c3pr thread.orig/thr_atfork.c thread/thr_atfork.c *** thread.orig/thr_atfork.c Tue Nov 4 19:42:10 2003 --- thread/thr_atfork.c Mon Jun 7 17:49:21 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_atfork, pthread_atfork); - int _pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void)) --- 31,36 ---- *************** _pthread_atfork(void (*prepare)(void), v *** 54,56 **** --- 52,55 ---- return (0); } + __strong_reference(_pthread_atfork, pthread_atfork); diff -c3pr thread.orig/thr_attr_destroy.c thread/thr_attr_destroy.c *** thread.orig/thr_attr_destroy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_destroy.c Mon Jun 7 17:49:31 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_destroy, pthread_attr_destroy); - int _pthread_attr_destroy(pthread_attr_t *attr) { --- 36,41 ---- *************** _pthread_attr_destroy(pthread_attr_t *at *** 60,62 **** --- 58,62 ---- } return(ret); } + + __strong_reference(_pthread_attr_destroy, pthread_attr_destroy); diff -c3pr thread.orig/thr_attr_get_np.c thread/thr_attr_get_np.c *** thread.orig/thr_attr_get_np.c Sun Jul 6 21:28:23 2003 --- thread/thr_attr_get_np.c Mon Jun 7 17:49:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_get_np, pthread_attr_get_np); - int _pthread_attr_get_np(pthread_t pid, pthread_attr_t *dst) { --- 31,36 ---- *************** _pthread_attr_get_np(pthread_t pid, pthr *** 52,54 **** --- 50,54 ---- return (0); } + + __strong_reference(_pthread_attr_get_np, pthread_attr_get_np); diff -c3pr thread.orig/thr_attr_getdetachstate.c thread/thr_attr_getdetachstate.c *** thread.orig/thr_attr_getdetachstate.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getdetachstate.c Mon Jun 7 17:49:50 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); - int _pthread_attr_getdetachstate(const pthread_attr_t *attr, int *detachstate) { --- 35,40 ---- *************** _pthread_attr_getdetachstate(const pthre *** 57,59 **** --- 55,59 ---- } return(ret); } + + __strong_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); diff -c3pr thread.orig/thr_attr_getguardsize.c thread/thr_attr_getguardsize.c *** thread.orig/thr_attr_getguardsize.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getguardsize.c Mon Jun 7 17:50:04 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); - int _pthread_attr_getguardsize(const pthread_attr_t *attr, size_t *guardsize) { --- 33,38 ---- *************** _pthread_attr_getguardsize(const pthread *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); diff -c3pr thread.orig/thr_attr_getinheritsched.c thread/thr_attr_getinheritsched.c *** thread.orig/thr_attr_getinheritsched.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getinheritsched.c Mon Jun 7 17:50:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); - int _pthread_attr_getinheritsched(const pthread_attr_t *attr, int *sched_inherit) { --- 35,40 ---- *************** _pthread_attr_getinheritsched(const pthr *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); diff -c3pr thread.orig/thr_attr_getschedparam.c thread/thr_attr_getschedparam.c *** thread.orig/thr_attr_getschedparam.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedparam.c Mon Jun 7 17:50:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); - int _pthread_attr_getschedparam(const pthread_attr_t *attr, struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_getschedparam(const pthrea *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); diff -c3pr thread.orig/thr_attr_getschedpolicy.c thread/thr_attr_getschedpolicy.c *** thread.orig/thr_attr_getschedpolicy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedpolicy.c Mon Jun 7 17:50:29 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); - int _pthread_attr_getschedpolicy(const pthread_attr_t *attr, int *policy) { --- 35,40 ---- *************** _pthread_attr_getschedpolicy(const pthre *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); diff -c3pr thread.orig/thr_attr_getscope.c thread/thr_attr_getscope.c *** thread.orig/thr_attr_getscope.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getscope.c Mon Jun 7 17:50:38 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getscope, pthread_attr_getscope); - int _pthread_attr_getscope(const pthread_attr_t *attr, int *contentionscope) { --- 35,40 ---- *************** _pthread_attr_getscope(const pthread_att *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_getscope, pthread_attr_getscope); diff -c3pr thread.orig/thr_attr_getstack.c thread/thr_attr_getstack.c *** thread.orig/thr_attr_getstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_getstack.c Mon Jun 7 17:50:46 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstack, pthread_attr_getstack); - int _pthread_attr_getstack(const pthread_attr_t * __restrict attr, void ** __restrict stackaddr, --- 35,40 ---- *************** _pthread_attr_getstack(const pthread_att *** 57,59 **** --- 55,58 ---- return(ret); } + __strong_reference(_pthread_attr_getstack, pthread_attr_getstack); diff -c3pr thread.orig/thr_attr_getstackaddr.c thread/thr_attr_getstackaddr.c *** thread.orig/thr_attr_getstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstackaddr.c Mon Jun 7 17:50:54 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); - int _pthread_attr_getstackaddr(const pthread_attr_t *attr, void **stackaddr) { --- 35,40 ---- *************** _pthread_attr_getstackaddr(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); diff -c3pr thread.orig/thr_attr_getstacksize.c thread/thr_attr_getstacksize.c *** thread.orig/thr_attr_getstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstacksize.c Mon Jun 7 17:51:02 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); - int _pthread_attr_getstacksize(const pthread_attr_t *attr, size_t *stacksize) { --- 35,40 ---- *************** _pthread_attr_getstacksize(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); diff -c3pr thread.orig/thr_attr_init.c thread/thr_attr_init.c *** thread.orig/thr_attr_init.c Thu Jul 17 19:46:55 2003 --- thread/thr_attr_init.c Mon Jun 7 17:51:11 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_init, pthread_attr_init); - int _pthread_attr_init(pthread_attr_t *attr) { --- 37,42 ---- *************** _pthread_attr_init(pthread_attr_t *attr) *** 61,63 **** --- 59,63 ---- } return(ret); } + + __strong_reference(_pthread_attr_init, pthread_attr_init); diff -c3pr thread.orig/thr_attr_setcreatesuspend_np.c thread/thr_attr_setcreatesuspend_np.c *** thread.orig/thr_attr_setcreatesuspend_np.c Thu Sep 25 06:53:49 2003 --- thread/thr_attr_setcreatesuspend_np.c Mon Jun 7 17:51:20 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); - int _pthread_attr_setcreatesuspend_np(pthread_attr_t *attr) { --- 35,40 ---- *************** _pthread_attr_setcreatesuspend_np(pthrea *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); diff -c3pr thread.orig/thr_attr_setdetachstate.c thread/thr_attr_setdetachstate.c *** thread.orig/thr_attr_setdetachstate.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setdetachstate.c Mon Jun 7 17:51:28 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); - int _pthread_attr_setdetachstate(pthread_attr_t *attr, int detachstate) { --- 35,40 ---- *************** _pthread_attr_setdetachstate(pthread_att *** 59,61 **** --- 57,61 ---- } return(ret); } + + __strong_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); diff -c3pr thread.orig/thr_attr_setguardsize.c thread/thr_attr_setguardsize.c *** thread.orig/thr_attr_setguardsize.c Sun Sep 14 15:39:44 2003 --- thread/thr_attr_setguardsize.c Mon Jun 7 17:51:39 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); - int _pthread_attr_setguardsize(pthread_attr_t *attr, size_t guardsize) { --- 34,39 ---- *************** _pthread_attr_setguardsize(pthread_attr_ *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); diff -c3pr thread.orig/thr_attr_setinheritsched.c thread/thr_attr_setinheritsched.c *** thread.orig/thr_attr_setinheritsched.c Sun Sep 14 15:28:13 2003 --- thread/thr_attr_setinheritsched.c Mon Jun 7 17:51:48 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); - int _pthread_attr_setinheritsched(pthread_attr_t *attr, int sched_inherit) { --- 35,40 ---- *************** _pthread_attr_setinheritsched(pthread_at *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); diff -c3pr thread.orig/thr_attr_setschedparam.c thread/thr_attr_setschedparam.c *** thread.orig/thr_attr_setschedparam.c Thu Apr 17 22:04:15 2003 --- thread/thr_attr_setschedparam.c Mon Jun 7 17:51:58 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); - int _pthread_attr_setschedparam(pthread_attr_t *attr, const struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_setschedparam(pthread_attr *** 55,57 **** --- 53,57 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); diff -c3pr thread.orig/thr_attr_setschedpolicy.c thread/thr_attr_setschedpolicy.c *** thread.orig/thr_attr_setschedpolicy.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setschedpolicy.c Mon Jun 7 17:52:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); - int _pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy) { --- 35,40 ---- *************** _pthread_attr_setschedpolicy(pthread_att *** 51,53 **** --- 49,53 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); diff -c3pr thread.orig/thr_attr_setscope.c thread/thr_attr_setscope.c *** thread.orig/thr_attr_setscope.c Sun Sep 14 15:32:28 2003 --- thread/thr_attr_setscope.c Mon Jun 7 17:52:24 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setscope, pthread_attr_setscope); - int _pthread_attr_setscope(pthread_attr_t *attr, int contentionscope) { --- 35,40 ---- *************** _pthread_attr_setscope(pthread_attr_t *a *** 55,57 **** --- 53,57 ---- } return (ret); } + + __strong_reference(_pthread_attr_setscope, pthread_attr_setscope); diff -c3pr thread.orig/thr_attr_setstack.c thread/thr_attr_setstack.c *** thread.orig/thr_attr_setstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_setstack.c Mon Jun 7 17:52:33 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstack, pthread_attr_setstack); - int _pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr, size_t stacksize) --- 35,40 ---- *************** _pthread_attr_setstack(pthread_attr_t *a *** 56,58 **** --- 54,57 ---- return(ret); } + __strong_reference(_pthread_attr_setstack, pthread_attr_setstack); diff -c3pr thread.orig/thr_attr_setstackaddr.c thread/thr_attr_setstackaddr.c *** thread.orig/thr_attr_setstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstackaddr.c Mon Jun 7 17:52:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); - int _pthread_attr_setstackaddr(pthread_attr_t *attr, void *stackaddr) { --- 35,40 ---- *************** _pthread_attr_setstackaddr(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); diff -c3pr thread.orig/thr_attr_setstacksize.c thread/thr_attr_setstacksize.c *** thread.orig/thr_attr_setstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstacksize.c Mon Jun 7 17:52:55 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); - int _pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize) { --- 35,40 ---- *************** _pthread_attr_setstacksize(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); diff -c3pr thread.orig/thr_barrier.c thread/thr_barrier.c *** thread.orig/thr_barrier.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrier.c Mon Jun 7 18:08:22 2004 *************** *** 33,42 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_barrier_init, pthread_barrier_init); - __weak_reference(_pthread_barrier_wait, pthread_barrier_wait); - __weak_reference(_pthread_barrier_destroy, pthread_barrier_destroy); - int _pthread_barrier_destroy(pthread_barrier_t *barrier) { --- 33,38 ---- *************** _pthread_barrier_destroy(pthread_barrier *** 58,64 **** int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, int count) { pthread_barrier_t bar; int ret; --- 54,60 ---- int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, unsigned count) { pthread_barrier_t bar; int ret; *************** _pthread_barrier_wait(pthread_barrier_t *** 120,122 **** --- 116,122 ---- _pthread_mutex_unlock(&bar->b_lock); return (ret); } + + __strong_reference(_pthread_barrier_init, pthread_barrier_init); + __strong_reference(_pthread_barrier_wait, pthread_barrier_wait); + __strong_reference(_pthread_barrier_destroy, pthread_barrier_destroy); diff -c3pr thread.orig/thr_barrierattr.c thread/thr_barrierattr.c *** thread.orig/thr_barrierattr.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrierattr.c Mon Jun 7 17:53:46 2004 *************** *** 33,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); - __weak_reference(_pthread_barrierattr_init, pthread_barrierattr_init); - __weak_reference(_pthread_barrierattr_setpshared, - pthread_barrierattr_setpshared); - __weak_reference(_pthread_barrierattr_getpshared, - pthread_barrierattr_getpshared); - int _pthread_barrierattr_destroy(pthread_barrierattr_t *attr) { --- 33,38 ---- *************** _pthread_barrierattr_setpshared(pthread_ *** 91,93 **** --- 84,93 ---- (*attr)->pshared = pshared; return (0); } + + __strong_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); + __strong_reference(_pthread_barrierattr_init, pthread_barrierattr_init); + __strong_reference(_pthread_barrierattr_setpshared, + pthread_barrierattr_setpshared); + __strong_reference(_pthread_barrierattr_getpshared, + pthread_barrierattr_getpshared); diff -c3pr thread.orig/thr_cancel.c thread/thr_cancel.c *** thread.orig/thr_cancel.c Mon Dec 8 18:20:56 2003 --- thread/thr_cancel.c Mon Jun 7 17:54:07 2004 *************** *** 6,16 **** #include #include "thr_private.h" - __weak_reference(_pthread_cancel, pthread_cancel); - __weak_reference(_pthread_setcancelstate, pthread_setcancelstate); - __weak_reference(_pthread_setcanceltype, pthread_setcanceltype); - __weak_reference(_pthread_testcancel, pthread_testcancel); - static inline int checkcancel(struct pthread *curthread) { --- 6,11 ---- *************** _thr_finish_cancellation(void *arg) *** 292,294 **** --- 287,294 ---- } THR_THREAD_UNLOCK(curthread, curthread); } + + __strong_reference(_pthread_cancel, pthread_cancel); + __strong_reference(_pthread_setcancelstate, pthread_setcancelstate); + __strong_reference(_pthread_setcanceltype, pthread_setcanceltype); + __strong_reference(_pthread_testcancel, pthread_testcancel); diff -c3pr thread.orig/thr_clean.c thread/thr_clean.c *** thread.orig/thr_clean.c Thu Apr 17 22:04:15 2003 --- thread/thr_clean.c Mon Jun 7 17:54:19 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_cleanup_push, pthread_cleanup_push); - __weak_reference(_pthread_cleanup_pop, pthread_cleanup_pop); - void _pthread_cleanup_push(void (*routine) (void *), void *routine_arg) { --- 37,42 ---- *************** _pthread_cleanup_pop(int execute) *** 70,72 **** --- 67,72 ---- free(old); } } + + __strong_reference(_pthread_cleanup_push, pthread_cleanup_push); + __strong_reference(_pthread_cleanup_pop, pthread_cleanup_pop); diff -c3pr thread.orig/thr_close.c thread/thr_close.c *** thread.orig/thr_close.c Mon Dec 8 18:20:56 2003 --- thread/thr_close.c Mon Jun 7 17:54:27 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(__close, close); - int __close(int fd) { --- 39,44 ---- *************** __close(int fd) *** 53,55 **** --- 51,55 ---- return (ret); } + + __strong_reference(__close, close); diff -c3pr thread.orig/thr_concurrency.c thread/thr_concurrency.c *** thread.orig/thr_concurrency.c Sat Mar 13 21:24:27 2004 --- thread/thr_concurrency.c Mon Jun 7 17:54:39 2004 *************** *** 42,50 **** static int level = 0; - __weak_reference(_pthread_getconcurrency, pthread_getconcurrency); - __weak_reference(_pthread_setconcurrency, pthread_setconcurrency); - int _pthread_getconcurrency(void) { --- 42,47 ---- *************** _thr_setmaxconcurrency(void) *** 163,165 **** --- 160,164 ---- return (ret); } + __strong_reference(_pthread_getconcurrency, pthread_getconcurrency); + __strong_reference(_pthread_setconcurrency, pthread_setconcurrency); diff -c3pr thread.orig/thr_cond.c thread/thr_cond.c *** thread.orig/thr_cond.c Mon Dec 8 18:20:56 2003 --- thread/thr_cond.c Mon Jun 7 17:55:06 2004 *************** static inline void cond_queue_enq(pthre *** 53,66 **** * versions are not and are provided for libc internal usage (which * shouldn't introduce cancellation points). */ - __weak_reference(__pthread_cond_wait, pthread_cond_wait); - __weak_reference(__pthread_cond_timedwait, pthread_cond_timedwait); - - __weak_reference(_pthread_cond_init, pthread_cond_init); - __weak_reference(_pthread_cond_destroy, pthread_cond_destroy); - __weak_reference(_pthread_cond_signal, pthread_cond_signal); - __weak_reference(_pthread_cond_broadcast, pthread_cond_broadcast); - int _pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *cond_attr) --- 53,58 ---- *************** cond_queue_enq(pthread_cond_t cond, stru *** 814,816 **** --- 806,816 ---- THR_CONDQ_SET(pthread); pthread->data.cond = cond; } + + __strong_reference(__pthread_cond_wait, pthread_cond_wait); + __strong_reference(__pthread_cond_timedwait, pthread_cond_timedwait); + + __strong_reference(_pthread_cond_init, pthread_cond_init); + __strong_reference(_pthread_cond_destroy, pthread_cond_destroy); + __strong_reference(_pthread_cond_signal, pthread_cond_signal); + __strong_reference(_pthread_cond_broadcast, pthread_cond_broadcast); diff -c3pr thread.orig/thr_condattr_destroy.c thread/thr_condattr_destroy.c *** thread.orig/thr_condattr_destroy.c Mon Sep 16 01:45:34 2002 --- thread/thr_condattr_destroy.c Mon Jun 7 17:55:17 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_destroy, pthread_condattr_destroy); - int _pthread_condattr_destroy(pthread_condattr_t *attr) { --- 36,41 ---- *************** _pthread_condattr_destroy(pthread_condat *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_condattr_destroy, pthread_condattr_destroy); diff -c3pr thread.orig/thr_condattr_init.c thread/thr_condattr_init.c *** thread.orig/thr_condattr_init.c Thu Apr 17 22:04:15 2003 --- thread/thr_condattr_init.c Mon Jun 7 17:55:25 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_init, pthread_condattr_init); - int _pthread_condattr_init(pthread_condattr_t *attr) { --- 37,42 ---- *************** _pthread_condattr_init(pthread_condattr_ *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_condattr_init, pthread_condattr_init); diff -c3pr thread.orig/thr_connect.c thread/thr_connect.c *** thread.orig/thr_connect.c Tue Dec 9 15:40:27 2003 --- thread/thr_connect.c Mon Jun 7 17:55:33 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__connect, connect); - int __connect(int fd, const struct sockaddr *name, socklen_t namelen) { --- 32,37 ---- *************** __connect(int fd, const struct sockaddr *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__connect, connect); diff -c3pr thread.orig/thr_creat.c thread/thr_creat.c *** thread.orig/thr_creat.c Mon Dec 8 18:20:56 2003 --- thread/thr_creat.c Mon Jun 7 17:55:46 2004 *************** *** 35,42 **** extern int __creat(const char *, mode_t); - __weak_reference(___creat, creat); - int ___creat(const char *path, mode_t mode) { --- 35,40 ---- *************** ___creat(const char *path, mode_t mode) *** 53,55 **** --- 51,55 ---- return ret; } + + __strong_reference(___creat, creat); diff -c3pr thread.orig/thr_create.c thread/thr_create.c *** thread.orig/thr_create.c Thu Jan 8 07:37:09 2004 --- thread/thr_create.c Mon Jun 7 17:55:55 2004 *************** static void free_stack(struct pthread_at *** 64,71 **** static void thread_start(struct pthread *curthread, void *(*start_routine) (void *), void *arg); - __weak_reference(_pthread_create, pthread_create); - /* * Some notes on new thread creation and first time initializion * to enable multi-threading. --- 64,69 ---- *************** thread_start(struct pthread *curthread, *** 355,357 **** --- 353,357 ---- /* This point should never be reached. */ PANIC("Thread has resumed after exit"); } + + __strong_reference(_pthread_create, pthread_create); diff -c3pr thread.orig/thr_detach.c thread/thr_detach.c *** thread.orig/thr_detach.c Tue Jul 22 19:11:07 2003 --- thread/thr_detach.c Mon Jun 7 17:56:04 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_detach, pthread_detach); - int _pthread_detach(pthread_t pthread) { --- 37,42 ---- *************** _pthread_detach(pthread_t pthread) *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (rval); } + + __strong_reference(_pthread_detach, pthread_detach); diff -c3pr thread.orig/thr_equal.c thread/thr_equal.c *** thread.orig/thr_equal.c Mon Sep 16 01:45:34 2002 --- thread/thr_equal.c Mon Jun 7 17:56:11 2004 *************** *** 34,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_equal, pthread_equal); - int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } --- 34,44 ---- #include #include "thr_private.h" int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } + + __strong_reference(_pthread_equal, pthread_equal); diff -c3pr thread.orig/thr_exit.c thread/thr_exit.c *** thread.orig/thr_exit.c Sun Sep 14 15:52:16 2003 --- thread/thr_exit.c Mon Jun 7 17:56:20 2004 *************** *** 42,49 **** void _pthread_exit(void *status); - __weak_reference(_pthread_exit, pthread_exit); - void _thr_exit(char *fname, int lineno, char *msg) { --- 42,47 ---- *************** _pthread_exit(void *status) *** 147,149 **** --- 145,149 ---- /* This point should not be reached. */ PANIC("Dead thread has resumed"); } + + __strong_reference(_pthread_exit, pthread_exit); diff -c3pr thread.orig/thr_fcntl.c thread/thr_fcntl.c *** thread.orig/thr_fcntl.c Mon Dec 8 18:20:56 2003 --- thread/thr_fcntl.c Mon Jun 7 17:56:29 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__fcntl, fcntl); - int __fcntl(int fd, int cmd,...) { --- 38,43 ---- *************** __fcntl(int fd, int cmd,...) *** 76,78 **** --- 74,78 ---- return (ret); } + + __strong_reference(__fcntl, fcntl); diff -c3pr thread.orig/thr_fork.c thread/thr_fork.c *** thread.orig/thr_fork.c Wed Nov 5 10:18:45 2003 --- thread/thr_fork.c Mon Jun 7 17:56:39 2004 *************** *** 49,56 **** */ #pragma weak __malloc_lock - __weak_reference(_fork, fork); - pid_t _fork(void) { --- 49,54 ---- *************** _fork(void) *** 122,124 **** --- 120,124 ---- /* Return the process ID: */ return (ret); } + + __strong_reference(_fork, fork); diff -c3pr thread.orig/thr_fsync.c thread/thr_fsync.c *** thread.orig/thr_fsync.c Mon Dec 8 18:20:56 2003 --- thread/thr_fsync.c Mon Jun 7 17:56:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(__fsync, fsync); - int __fsync(int fd) { --- 35,40 ---- *************** __fsync(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(__fsync, fsync); diff -c3pr thread.orig/thr_getprio.c thread/thr_getprio.c *** thread.orig/thr_getprio.c Mon Sep 16 01:45:34 2002 --- thread/thr_getprio.c Mon Jun 7 17:56:56 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getprio, pthread_getprio); - int _pthread_getprio(pthread_t pthread) { --- 35,40 ---- *************** _pthread_getprio(pthread_t pthread) *** 54,56 **** --- 52,56 ---- /* Return the thread priority or an error status: */ return (ret); } + + __strong_reference(_pthread_getprio, pthread_getprio); diff -c3pr thread.orig/thr_getschedparam.c thread/thr_getschedparam.c *** thread.orig/thr_getschedparam.c Sun Jul 6 21:28:23 2003 --- thread/thr_getschedparam.c Mon Jun 7 17:57:03 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getschedparam, pthread_getschedparam); - int _pthread_getschedparam(pthread_t pthread, int *policy, struct sched_param *param) --- 35,40 ---- *************** _pthread_getschedparam(pthread_t pthread *** 73,75 **** --- 71,75 ---- } return (ret); } + + __strong_reference(_pthread_getschedparam, pthread_getschedparam); diff -c3pr thread.orig/thr_info.c thread/thr_info.c *** thread.orig/thr_info.c Sun Sep 21 17:40:23 2003 --- thread/thr_info.c Mon Jun 7 18:08:53 2004 *************** *** 46,53 **** static void dump_thread(int fd, pthread_t pthread, int long_version); - __weak_reference(_pthread_set_name_np, pthread_set_name_np); - struct s_thread_info { enum pthread_state state; char *name; --- 46,51 ---- *************** dump_thread(int fd, pthread_t pthread, i *** 212,218 **** /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { --- 210,216 ---- /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, const char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { *************** _pthread_set_name_np(pthread_t thread, c *** 223,225 **** --- 221,225 ---- thread->name = strdup(name); } } + + __strong_reference(_pthread_set_name_np, pthread_set_name_np); diff -c3pr thread.orig/thr_join.c thread/thr_join.c *** thread.orig/thr_join.c Mon Dec 8 18:20:56 2003 --- thread/thr_join.c Mon Jun 7 17:57:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_join, pthread_join); - int _pthread_join(pthread_t pthread, void **thread_return) { --- 35,40 ---- *************** _pthread_join(pthread_t pthread, void ** *** 160,162 **** --- 158,162 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_join, pthread_join); diff -c3pr thread.orig/thr_kill.c thread/thr_kill.c *** thread.orig/thr_kill.c Sat Jun 28 02:55:02 2003 --- thread/thr_kill.c Mon Jun 7 17:57:29 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_kill, pthread_kill); - int _pthread_kill(pthread_t pthread, int sig) { --- 36,41 ---- *************** _pthread_kill(pthread_t pthread, int sig *** 64,66 **** --- 62,66 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_kill, pthread_kill); diff -c3pr thread.orig/thr_main_np.c thread/thr_main_np.c *** thread.orig/thr_main_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_main_np.c Mon Jun 7 17:57:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_main_np, pthread_main_np); - /* * Provide the equivelant to Solaris thr_main() function */ --- 31,36 ---- *************** _pthread_main_np() *** 45,47 **** --- 43,47 ---- else return (pthread_equal(pthread_self(), _thr_initial) ? 1 : 0); } + + __strong_reference(_pthread_main_np, pthread_main_np); diff -c3pr thread.orig/thr_mattr_init.c thread/thr_mattr_init.c *** thread.orig/thr_mattr_init.c Thu Apr 17 22:04:16 2003 --- thread/thr_mattr_init.c Mon Jun 7 17:57:51 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_init, pthread_mutexattr_init); - int _pthread_mutexattr_init(pthread_mutexattr_t *attr) { --- 37,42 ---- *************** _pthread_mutexattr_init(pthread_mutexatt *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_mutexattr_init, pthread_mutexattr_init); diff -c3pr thread.orig/thr_mattr_kind_np.c thread/thr_mattr_kind_np.c *** thread.orig/thr_mattr_kind_np.c Mon Sep 16 01:45:35 2002 --- thread/thr_mattr_kind_np.c Mon Jun 7 17:58:11 2004 *************** *** 35,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); - __weak_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); - __weak_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); - __weak_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); - int _pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int kind) { --- 35,40 ---- *************** _pthread_mutexattr_gettype(pthread_mutex *** 95,97 **** --- 90,97 ---- } return ret; } + + __strong_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); + __strong_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); + __strong_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); + __strong_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); diff -c3pr thread.orig/thr_msync.c thread/thr_msync.c *** thread.orig/thr_msync.c Mon Dec 8 18:20:56 2003 --- thread/thr_msync.c Mon Jun 7 17:58:24 2004 *************** *** 11,18 **** #include #include "thr_private.h" - __weak_reference(__msync, msync); - int __msync(void *addr, size_t len, int flags) { --- 11,16 ---- *************** __msync(void *addr, size_t len, int flag *** 31,33 **** --- 29,33 ---- return ret; } + + __strong_reference(__msync, msync); diff -c3pr thread.orig/thr_multi_np.c thread/thr_multi_np.c *** thread.orig/thr_multi_np.c Thu May 23 21:32:28 2002 --- thread/thr_multi_np.c Mon Jun 7 17:58:35 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_multi_np, pthread_multi_np); - int _pthread_multi_np() { --- 34,39 ---- *************** _pthread_multi_np() *** 48,50 **** --- 46,50 ---- pthread_resume_all_np(); return (0); } + + __strong_reference(_pthread_multi_np, pthread_multi_np); diff -c3pr thread.orig/thr_mutex.c thread/thr_mutex.c *** thread.orig/thr_mutex.c Fri Jan 16 19:09:57 2004 --- thread/thr_mutex.c Mon Jun 7 17:59:07 2004 *************** static struct pthread_mutex_attr static_ *** 91,108 **** PTHREAD_MUTEXATTR_STATIC_INITIALIZER; static pthread_mutexattr_t static_mattr = &static_mutex_attr; - /* Single underscore versions provided for libc internal usage: */ - __weak_reference(__pthread_mutex_lock, pthread_mutex_lock); - __weak_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); - __weak_reference(__pthread_mutex_trylock, pthread_mutex_trylock); - - /* No difference between libc and application usage of these: */ - __weak_reference(_pthread_mutex_init, pthread_mutex_init); - __weak_reference(_pthread_mutex_destroy, pthread_mutex_destroy); - __weak_reference(_pthread_mutex_unlock, pthread_mutex_unlock); - - - int _pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutex_attr) --- 91,96 ---- *************** mutex_queue_enq(pthread_mutex_t mutex, p *** 1756,1758 **** --- 1744,1756 ---- } pthread->sflags |= THR_FLAGS_IN_SYNCQ; } + + /* Single underscore versions provided for libc internal usage: */ + __strong_reference(__pthread_mutex_lock, pthread_mutex_lock); + __strong_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); + __strong_reference(__pthread_mutex_trylock, pthread_mutex_trylock); + + /* No difference between libc and application usage of these: */ + __strong_reference(_pthread_mutex_init, pthread_mutex_init); + __strong_reference(_pthread_mutex_destroy, pthread_mutex_destroy); + __strong_reference(_pthread_mutex_unlock, pthread_mutex_unlock); diff -c3pr thread.orig/thr_mutex_prioceiling.c thread/thr_mutex_prioceiling.c *** thread.orig/thr_mutex_prioceiling.c Sun Jul 6 21:28:23 2003 --- thread/thr_mutex_prioceiling.c Mon Jun 7 17:59:30 2004 *************** *** 37,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); - __weak_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); - __weak_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); - __weak_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); - int _pthread_mutexattr_getprioceiling(pthread_mutexattr_t *mattr, int *prioceiling) { --- 37,42 ---- *************** _pthread_mutex_setprioceiling(pthread_mu *** 113,115 **** --- 108,115 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); + __strong_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); + __strong_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); + __strong_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); diff -c3pr thread.orig/thr_mutex_protocol.c thread/thr_mutex_protocol.c *** thread.orig/thr_mutex_protocol.c Thu Apr 17 22:04:16 2003 --- thread/thr_mutex_protocol.c Mon Jun 7 17:59:53 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); - __weak_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); - int _pthread_mutexattr_getprotocol(pthread_mutexattr_t *mattr, int *protocol) { --- 37,42 ---- *************** _pthread_mutexattr_setprotocol(pthread_m *** 68,70 **** --- 65,69 ---- return(ret); } + __strong_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); + __strong_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); diff -c3pr thread.orig/thr_mutexattr_destroy.c thread/thr_mutexattr_destroy.c *** thread.orig/thr_mutexattr_destroy.c Mon Sep 16 01:45:35 2002 --- thread/thr_mutexattr_destroy.c Mon Jun 7 18:00:04 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); - int _pthread_mutexattr_destroy(pthread_mutexattr_t *attr) { --- 36,41 ---- *************** _pthread_mutexattr_destroy(pthread_mutex *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); diff -c3pr thread.orig/thr_nanosleep.c thread/thr_nanosleep.c *** thread.orig/thr_nanosleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_nanosleep.c Mon Jun 7 18:00:12 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(__nanosleep, nanosleep); - int _nanosleep(const struct timespec *time_to_sleep, struct timespec *time_remaining) --- 36,41 ---- *************** __nanosleep(const struct timespec *time_ *** 127,129 **** --- 125,129 ---- return (ret); } + + __strong_reference(__nanosleep, nanosleep); diff -c3pr thread.orig/thr_once.c thread/thr_once.c *** thread.orig/thr_once.c Tue Sep 9 15:38:12 2003 --- thread/thr_once.c Mon Jun 7 18:00:24 2004 *************** *** 36,43 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_once, pthread_once); - #define ONCE_NEVER_DONE PTHREAD_NEEDS_INIT #define ONCE_DONE PTHREAD_DONE_INIT #define ONCE_IN_PROGRESS 0x02 --- 36,41 ---- *************** _pthread_once(pthread_once_t *once_contr *** 94,96 **** --- 92,95 ---- return (0); } + __strong_reference(_pthread_once, pthread_once); diff -c3pr thread.orig/thr_open.c thread/thr_open.c *** thread.orig/thr_open.c Mon Dec 8 18:20:56 2003 --- thread/thr_open.c Mon Jun 7 18:00:32 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__open, open); - int __open(const char *path, int flags,...) { --- 40,45 ---- *************** __open(const char *path, int flags,...) *** 69,71 **** --- 67,71 ---- return ret; } + + __strong_reference(__open, open); diff -c3pr thread.orig/thr_pause.c thread/thr_pause.c *** thread.orig/thr_pause.c Mon Dec 8 18:20:56 2003 --- thread/thr_pause.c Mon Jun 7 18:00:43 2004 *************** *** 35,42 **** extern int __pause(void); - __weak_reference(_pause, pause); - int _pause(void) { --- 35,40 ---- *************** _pause(void) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_pause, pause); diff -c3pr thread.orig/thr_poll.c thread/thr_poll.c *** thread.orig/thr_poll.c Mon Dec 8 18:20:56 2003 --- thread/thr_poll.c Mon Jun 7 18:00:57 2004 *************** *** 41,47 **** #include #include "thr_private.h" - __weak_reference(__poll, poll); int __poll(struct pollfd *fds, unsigned int nfds, int timeout) --- 41,46 ---- *************** __poll(struct pollfd *fds, unsigned int *** 55,57 **** --- 54,58 ---- return ret; } + + __strong_reference(__poll, poll); diff -c3pr thread.orig/thr_pselect.c thread/thr_pselect.c *** thread.orig/thr_pselect.c Mon Dec 8 18:20:56 2003 --- thread/thr_pselect.c Mon Jun 7 18:01:06 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 40,47 **** extern int __pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask); - __weak_reference(_pselect, pselect); - int _pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask) --- 40,45 ---- *************** _pselect(int count, fd_set *rfds, fd_set *** 55,57 **** --- 53,57 ---- return (ret); } + + __strong_reference(_pselect, pselect); diff -c3pr thread.orig/thr_pspinlock.c thread/thr_pspinlock.c *** thread.orig/thr_pspinlock.c Tue Nov 4 11:56:12 2003 --- thread/thr_pspinlock.c Mon Jun 7 18:01:16 2004 *************** *** 34,45 **** #define SPIN_COUNT 10000 - __weak_reference(_pthread_spin_init, pthread_spin_init); - __weak_reference(_pthread_spin_destroy, pthread_spin_destroy); - __weak_reference(_pthread_spin_trylock, pthread_spin_trylock); - __weak_reference(_pthread_spin_lock, pthread_spin_lock); - __weak_reference(_pthread_spin_unlock, pthread_spin_unlock); - int _pthread_spin_init(pthread_spinlock_t *lock, int pshared) { --- 34,39 ---- *************** _pthread_spin_unlock(pthread_spinlock_t *** 158,160 **** --- 152,159 ---- return (ret); } + __strong_reference(_pthread_spin_init, pthread_spin_init); + __strong_reference(_pthread_spin_destroy, pthread_spin_destroy); + __strong_reference(_pthread_spin_trylock, pthread_spin_trylock); + __strong_reference(_pthread_spin_lock, pthread_spin_lock); + __strong_reference(_pthread_spin_unlock, pthread_spin_unlock); diff -c3pr thread.orig/thr_raise.c thread/thr_raise.c *** thread.orig/thr_raise.c Fri Jul 18 22:25:49 2003 --- thread/thr_raise.c Mon Jun 7 18:01:27 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_raise, raise); - int _raise(int sig) { --- 33,38 ---- *************** _raise(int sig) *** 51,53 **** --- 49,53 ---- } return (ret); } + + __strong_reference(_raise, raise); diff -c3pr thread.orig/thr_read.c thread/thr_read.c *** thread.orig/thr_read.c Mon Dec 8 18:20:56 2003 --- thread/thr_read.c Mon Jun 7 18:01:40 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__read, read); - ssize_t __read(int fd, void *buf, size_t nbytes) { --- 40,45 ---- *************** __read(int fd, void *buf, size_t nbytes) *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__read, read); diff -c3pr thread.orig/thr_readv.c thread/thr_readv.c *** thread.orig/thr_readv.c Mon Dec 8 18:20:56 2003 --- thread/thr_readv.c Mon Jun 7 18:01:57 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__readv, readv); - ssize_t __readv(int fd, const struct iovec *iov, int iovcnt) { --- 40,45 ---- *************** __readv(int fd, const struct iovec *iov, *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__readv, readv); diff -c3pr thread.orig/thr_resume_np.c thread/thr_resume_np.c *** thread.orig/thr_resume_np.c Tue Jul 22 19:11:07 2003 --- thread/thr_resume_np.c Mon Jun 7 18:02:16 2004 *************** *** 37,46 **** static struct kse_mailbox *resume_common(struct pthread *); - __weak_reference(_pthread_resume_np, pthread_resume_np); - __weak_reference(_pthread_resume_all_np, pthread_resume_all_np); - - /* Resume a thread: */ int _pthread_resume_np(pthread_t thread) --- 37,42 ---- *************** resume_common(struct pthread *thread) *** 105,107 **** --- 101,106 ---- else return (NULL); } + + __strong_reference(_pthread_resume_np, pthread_resume_np); + __strong_reference(_pthread_resume_all_np, pthread_resume_all_np); diff -c3pr thread.orig/thr_rwlock.c thread/thr_rwlock.c *** thread.orig/thr_rwlock.c Thu Jan 8 07:37:09 2004 --- thread/thr_rwlock.c Mon Jun 7 18:02:29 2004 *************** *** 38,53 **** /* maximum number of times a read lock may be obtained */ #define MAX_READ_LOCKS (INT_MAX - 1) - __weak_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); - __weak_reference(_pthread_rwlock_init, pthread_rwlock_init); - __weak_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); - __weak_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); - __weak_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); - __weak_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); - __weak_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); - __weak_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); - __weak_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); - /* * Prototypes */ --- 38,43 ---- *************** _pthread_rwlock_timedwrlock (pthread_rwl *** 417,419 **** --- 407,419 ---- { return (rwlock_wrlock_common (rwlock, abstime)); } + + __strong_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); + __strong_reference(_pthread_rwlock_init, pthread_rwlock_init); + __strong_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); + __strong_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); + __strong_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); + __strong_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); + __strong_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); + __strong_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); + __strong_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); diff -c3pr thread.orig/thr_rwlockattr.c thread/thr_rwlockattr.c *** thread.orig/thr_rwlockattr.c Mon Sep 16 01:45:35 2002 --- thread/thr_rwlockattr.c Mon Jun 7 18:02:44 2004 *************** *** 32,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); - __weak_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); - __weak_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); - __weak_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); - int _pthread_rwlockattr_destroy(pthread_rwlockattr_t *rwlockattr) { --- 32,37 ---- *************** _pthread_rwlockattr_setpshared(pthread_r *** 96,98 **** --- 91,97 ---- return(0); } + __strong_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); + __strong_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); + __strong_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); + __strong_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); diff -c3pr thread.orig/thr_select.c thread/thr_select.c *** thread.orig/thr_select.c Mon Dec 8 18:20:56 2003 --- thread/thr_select.c Mon Jun 7 18:02:56 2004 *************** *** 43,50 **** #include #include "thr_private.h" - __weak_reference(__select, select); - int __select(int numfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) --- 43,48 ---- *************** __select(int numfds, fd_set *readfds, fd *** 63,65 **** --- 61,65 ---- } return ret; } + + __strong_reference(__select, select); diff -c3pr thread.orig/thr_self.c thread/thr_self.c *** thread.orig/thr_self.c Thu Apr 17 22:04:16 2003 --- thread/thr_self.c Mon Jun 7 18:03:06 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_self, pthread_self); - pthread_t _pthread_self(void) { --- 34,39 ---- *************** _pthread_self(void) *** 45,47 **** --- 43,47 ---- /* Return the running thread pointer: */ return (_get_curthread()); } + + __strong_reference(_pthread_self, pthread_self); diff -c3pr thread.orig/thr_sem.c thread/thr_sem.c *** thread.orig/thr_sem.c Fri Feb 6 07:20:56 2004 --- thread/thr_sem.c Mon Jun 7 18:09:50 2004 *************** extern int pthread_cond_wait(pthread_con *** 47,58 **** extern int pthread_cond_timedwait(pthread_cond_t *, pthread_mutex_t *, struct timespec *); - __weak_reference(_sem_init, sem_init); - __weak_reference(_sem_wait, sem_wait); - __weak_reference(_sem_timedwait, sem_timedwait); - __weak_reference(_sem_post, sem_post); - - static inline int sem_check_validity(sem_t *sem) { --- 47,52 ---- *************** _sem_wait(sem_t *sem) *** 173,179 **** int _sem_timedwait(sem_t * __restrict sem, ! struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; --- 167,173 ---- int _sem_timedwait(sem_t * __restrict sem, ! const struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; *************** _sem_post(sem_t *sem) *** 260,262 **** --- 254,261 ---- return (retval); } + + __strong_reference(_sem_init, sem_init); + __strong_reference(_sem_wait, sem_wait); + __strong_reference(_sem_timedwait, sem_timedwait); + __strong_reference(_sem_post, sem_post); diff -c3pr thread.orig/thr_setprio.c thread/thr_setprio.c *** thread.orig/thr_setprio.c Mon Sep 16 01:45:36 2002 --- thread/thr_setprio.c Mon Jun 7 18:03:28 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_setprio, pthread_setprio); - int _pthread_setprio(pthread_t pthread, int prio) { --- 34,39 ---- *************** _pthread_setprio(pthread_t pthread, int *** 50,52 **** --- 48,52 ---- /* Return the error status: */ return (ret); } + + __strong_reference(_pthread_setprio, pthread_setprio); diff -c3pr thread.orig/thr_setschedparam.c thread/thr_setschedparam.c *** thread.orig/thr_setschedparam.c Sun Apr 20 21:02:56 2003 --- thread/thr_setschedparam.c Mon Jun 7 18:03:37 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_setschedparam, pthread_setschedparam); - int _pthread_setschedparam(pthread_t pthread, int policy, const struct sched_param *param) --- 36,41 ---- *************** _pthread_setschedparam(pthread_t pthread *** 134,136 **** --- 132,136 ---- } return (ret); } + + __strong_reference(_pthread_setschedparam, pthread_setschedparam); diff -c3pr thread.orig/thr_sigaction.c thread/thr_sigaction.c *** thread.orig/thr_sigaction.c Wed Sep 24 23:23:40 2003 --- thread/thr_sigaction.c Mon Jun 7 18:03:50 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_sigaction, sigaction); - int _sigaction(int sig, const struct sigaction * act, struct sigaction * oact) { --- 36,41 ---- *************** _sigaction(int sig, const struct sigacti *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigaction, sigaction); diff -c3pr thread.orig/thr_sigaltstack.c thread/thr_sigaltstack.c *** thread.orig/thr_sigaltstack.c Thu Jan 1 16:38:42 2004 --- thread/thr_sigaltstack.c Mon Jun 7 18:10:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 31,40 **** #include #include "thr_private.h" - __weak_reference(_sigaltstack, sigaltstack); - int ! _sigaltstack(stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; --- 31,38 ---- #include #include "thr_private.h" int ! _sigaltstack(const stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; *************** _thr_sigonstack(void *sp) *** 105,107 **** --- 103,106 ---- : 0); } + __strong_reference(_sigaltstack, sigaltstack); diff -c3pr thread.orig/thr_sigmask.c thread/thr_sigmask.c *** thread.orig/thr_sigmask.c Thu Sep 18 05:19:28 2003 --- thread/thr_sigmask.c Mon Jun 7 18:04:07 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_sigmask, pthread_sigmask); - int _pthread_sigmask(int how, const sigset_t *set, sigset_t *oset) { --- 40,45 ---- *************** _pthread_sigmask(int how, const sigset_t *** 111,113 **** --- 109,113 ---- *oset = oldset; return (ret); } + + __strong_reference(_pthread_sigmask, pthread_sigmask); diff -c3pr thread.orig/thr_sigpending.c thread/thr_sigpending.c *** thread.orig/thr_sigpending.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigpending.c Mon Jun 7 18:04:15 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigpending, sigpending); - int _sigpending(sigset_t *set) { --- 39,44 ---- *************** _sigpending(sigset_t *set) *** 71,73 **** --- 69,73 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigpending, sigpending); diff -c3pr thread.orig/thr_sigprocmask.c thread/thr_sigprocmask.c *** thread.orig/thr_sigprocmask.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigprocmask.c Mon Jun 7 18:04:24 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigprocmask, sigprocmask); - int _sigprocmask(int how, const sigset_t *set, sigset_t *oset) { --- 39,44 ---- *************** _sigprocmask(int how, const sigset_t *se *** 53,55 **** --- 51,55 ---- } return (ret); } + + __strong_reference(_sigprocmask, sigprocmask); diff -c3pr thread.orig/thr_sigsuspend.c thread/thr_sigsuspend.c *** thread.orig/thr_sigsuspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_sigsuspend.c Mon Jun 7 18:04:32 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__sigsuspend, sigsuspend); - int _sigsuspend(const sigset_t *set) { --- 38,43 ---- *************** __sigsuspend(const sigset_t * set) *** 101,103 **** --- 99,103 ---- return (ret); } + + __strong_reference(__sigsuspend, sigsuspend); diff -c3pr thread.orig/thr_sigwait.c thread/thr_sigwait.c *** thread.orig/thr_sigwait.c Tue Mar 16 18:12:19 2004 --- thread/thr_sigwait.c Mon Jun 7 18:04:44 2004 *************** *** 39,48 **** #include #include "thr_private.h" - __weak_reference(__sigwait, sigwait); - __weak_reference(__sigtimedwait, sigtimedwait); - __weak_reference(__sigwaitinfo, sigwaitinfo); - static int lib_sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec * timeout) --- 39,44 ---- *************** _sigwait(const sigset_t *set, int *sig) *** 200,202 **** --- 196,201 ---- return (ret); } + __strong_reference(__sigwait, sigwait); + __strong_reference(__sigtimedwait, sigtimedwait); + __strong_reference(__sigwaitinfo, sigwaitinfo); diff -c3pr thread.orig/thr_single_np.c thread/thr_single_np.c *** thread.orig/thr_single_np.c Thu May 23 21:32:28 2002 --- thread/thr_single_np.c Mon Jun 7 18:04:56 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_single_np, pthread_single_np); - int _pthread_single_np() { --- 34,39 ---- *************** int _pthread_single_np() *** 47,49 **** --- 45,49 ---- */ return (0); } + + __strong_reference(_pthread_single_np, pthread_single_np); diff -c3pr thread.orig/thr_sleep.c thread/thr_sleep.c *** thread.orig/thr_sleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_sleep.c Mon Jun 7 18:05:04 2004 *************** *** 35,42 **** extern unsigned int __sleep(unsigned int); - __weak_reference(_sleep, sleep); - unsigned int _sleep(unsigned int seconds) { --- 35,40 ---- *************** _sleep(unsigned int seconds) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_sleep, sleep); diff -c3pr thread.orig/thr_spec.c thread/thr_spec.c *** thread.orig/thr_spec.c Tue Aug 19 19:34:14 2003 --- thread/thr_spec.c Mon Jun 7 18:05:14 2004 *************** struct pthread_key { *** 48,59 **** /* Static variables: */ static struct pthread_key key_table[PTHREAD_KEYS_MAX]; - __weak_reference(_pthread_key_create, pthread_key_create); - __weak_reference(_pthread_key_delete, pthread_key_delete); - __weak_reference(_pthread_getspecific, pthread_getspecific); - __weak_reference(_pthread_setspecific, pthread_setspecific); - - int _pthread_key_create(pthread_key_t *key, void (*destructor) (void *)) { --- 48,53 ---- *************** _pthread_getspecific(pthread_key_t key) *** 232,234 **** --- 226,233 ---- data = NULL; return (data); } + + __strong_reference(_pthread_key_create, pthread_key_create); + __strong_reference(_pthread_key_delete, pthread_key_delete); + __strong_reference(_pthread_getspecific, pthread_getspecific); + __strong_reference(_pthread_setspecific, pthread_setspecific); diff -c3pr thread.orig/thr_suspend_np.c thread/thr_suspend_np.c *** thread.orig/thr_suspend_np.c Sun May 4 09:17:01 2003 --- thread/thr_suspend_np.c Mon Jun 7 18:05:26 2004 *************** *** 37,45 **** static void suspend_common(struct pthread *thread); - __weak_reference(_pthread_suspend_np, pthread_suspend_np); - __weak_reference(_pthread_suspend_all_np, pthread_suspend_all_np); - /* Suspend a thread: */ int _pthread_suspend_np(pthread_t thread) --- 37,42 ---- *************** suspend_common(struct pthread *thread) *** 107,109 **** --- 104,109 ---- #endif } } + + __strong_reference(_pthread_suspend_np, pthread_suspend_np); + __strong_reference(_pthread_suspend_all_np, pthread_suspend_all_np); diff -c3pr thread.orig/thr_switch_np.c thread/thr_switch_np.c *** thread.orig/thr_switch_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_switch_np.c Mon Jun 7 18:05:36 2004 *************** *** 36,45 **** #include #include "thr_private.h" - - __weak_reference(_pthread_switch_add_np, pthread_switch_add_np); - __weak_reference(_pthread_switch_delete_np, pthread_switch_delete_np); - int _pthread_switch_add_np(pthread_switch_routine_t routine) { --- 36,41 ---- *************** _pthread_switch_delete_np(pthread_switch *** 51,53 **** --- 47,52 ---- { return (ENOTSUP); } + + __strong_reference(_pthread_switch_add_np, pthread_switch_add_np); + __strong_reference(_pthread_switch_delete_np, pthread_switch_delete_np); diff -c3pr thread.orig/thr_system.c thread/thr_system.c *** thread.orig/thr_system.c Mon Dec 8 18:20:56 2003 --- thread/thr_system.c Mon Jun 7 18:05:44 2004 *************** *** 35,42 **** extern int __system(const char *); - __weak_reference(_system, system); - int _system(const char *string) { --- 35,40 ---- *************** _system(const char *string) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_system, system); diff -c3pr thread.orig/thr_tcdrain.c thread/thr_tcdrain.c *** thread.orig/thr_tcdrain.c Mon Dec 8 18:20:56 2003 --- thread/thr_tcdrain.c Mon Jun 7 18:05:54 2004 *************** *** 35,42 **** extern int __tcdrain(int); - __weak_reference(_tcdrain, tcdrain); - int _tcdrain(int fd) { --- 35,40 ---- *************** _tcdrain(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_tcdrain, tcdrain); diff -c3pr thread.orig/thr_vfork.c thread/thr_vfork.c *** thread.orig/thr_vfork.c Mon Apr 9 21:19:20 2001 --- thread/thr_vfork.c Mon Jun 7 18:06:04 2004 *************** *** 3,12 **** */ #include - __weak_reference(_vfork, vfork); - int _vfork(void) { return (fork()); } --- 3,12 ---- */ #include int _vfork(void) { return (fork()); } + + __strong_reference(_vfork, vfork); diff -c3pr thread.orig/thr_wait.c thread/thr_wait.c *** thread.orig/thr_wait.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait.c Mon Jun 7 18:06:12 2004 *************** *** 34,41 **** extern int __wait(int *); - __weak_reference(_wait, wait); - pid_t _wait(int *istat) { --- 34,39 ---- *************** _wait(int *istat) *** 48,50 **** --- 46,50 ---- return ret; } + + __strong_reference(_wait, wait); diff -c3pr thread.orig/thr_wait4.c thread/thr_wait4.c *** thread.orig/thr_wait4.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait4.c Mon Jun 7 18:06:20 2004 *************** *** 41,48 **** #include "thr_private.h" - __weak_reference(__wait4, wait4); - pid_t __wait4(pid_t pid, int *istat, int options, struct rusage *rusage) { --- 41,46 ---- *************** __wait4(pid_t pid, int *istat, int optio *** 55,57 **** --- 53,57 ---- return ret; } + + __strong_reference(__wait4, wait4); diff -c3pr thread.orig/thr_waitpid.c thread/thr_waitpid.c *** thread.orig/thr_waitpid.c Mon Dec 8 18:20:56 2003 --- thread/thr_waitpid.c Mon Jun 7 18:06:29 2004 *************** *** 36,43 **** extern int __waitpid(pid_t, int *, int); - __weak_reference(_waitpid, waitpid); - pid_t _waitpid(pid_t wpid, int *status, int options) { --- 36,41 ---- *************** _waitpid(pid_t wpid, int *status, int op *** 50,52 **** --- 48,52 ---- return ret; } + + __strong_reference(_waitpid, waitpid); diff -c3pr thread.orig/thr_write.c thread/thr_write.c *** thread.orig/thr_write.c Mon Dec 8 18:20:56 2003 --- thread/thr_write.c Mon Jun 7 18:06:37 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__write, write); - ssize_t __write(int fd, const void *buf, size_t nbytes) { --- 40,45 ---- *************** __write(int fd, const void *buf, size_t *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__write, write); diff -c3pr thread.orig/thr_writev.c thread/thr_writev.c *** thread.orig/thr_writev.c Mon Dec 8 18:20:56 2003 --- thread/thr_writev.c Mon Jun 7 18:06:45 2004 *************** *** 42,49 **** #include #include "thr_private.h" - __weak_reference(__writev, writev); - ssize_t __writev(int fd, const struct iovec *iov, int iovcnt) { --- 42,47 ---- *************** __writev(int fd, const struct iovec *iov *** 56,58 **** --- 54,58 ---- return ret; } + + __strong_reference(__writev, writev); diff -c3pr thread.orig/thr_yield.c thread/thr_yield.c *** thread.orig/thr_yield.c Sun Aug 17 20:58:29 2003 --- thread/thr_yield.c Mon Jun 7 18:06:55 2004 *************** *** 34,42 **** #include #include "thr_private.h" - __weak_reference(_sched_yield, sched_yield); - __weak_reference(_pthread_yield, pthread_yield); - int _sched_yield(void) { --- 34,39 ---- *************** _pthread_yield(void) *** 71,73 **** --- 68,73 ---- /* Schedule the next thread: */ _thr_sched_switch(curthread); } + + __strong_reference(_sched_yield, sched_yield); + __strong_reference(_pthread_yield, pthread_yield); From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 03:19:25 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE20F16A4CE; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45EA743D2F; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.174) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002EB19C; Tue, 8 Jun 2004 13:19:23 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 567F841CE; Tue, 8 Jun 2004 13:21:11 +1000 (EST) Date: Tue, 8 Jun 2004 13:21:11 +1000 From: Tim Robbins To: Sean McNeil Message-ID: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:19:26 -0000 On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. > > The problem: > > (If you just want kse threads to work for you properly, just apply the > patch at the end of this email and try it out). > > kse threads on amd64 doesn't work with gnome. It crashes applications > here and there. gnome-terminal is essentially unusable. > > I strongly believe this to be a binding issue. I've examined rtld and > I'm satisfied that it is behaving appropriately, so I took a long hard > look at how FreeBSD has implemented the pthread interface, how it is > being used, and how people expect it to behave. [...] Your patch looks useful in its own right, but GNOME, Firefox, Mozilla and XMMS have not crashed once for me since I fixed context restoring in libpthread on amd64. Strong references cannot possibly make the old version of context.S work correctly. I would be interested in hearing whether you still have problems with libpthread and GNOME after updating your system, both with and without nss_ldap. Tim From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 03:33:11 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7783816A4CE; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B3FA43D53; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 0A710FD06C; Mon, 7 Jun 2004 20:33:11 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-05; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 90B6EFD01A; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) From: Sean McNeil To: Tim Robbins In-Reply-To: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608032111.GA43718@cat.robbins.dropbear.id.au> Content-Type: text/plain Message-Id: <1086665590.1817.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 20:33:10 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:33:11 -0000 On Mon, 2004-06-07 at 20:21, Tim Robbins wrote: > On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > > > > Up front, I'd like to make a few apologies: > > > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfully > > have to disagree. This email will hopefully strengthen my position. > > > > The problem: > > > > (If you just want kse threads to work for you properly, just apply the > > patch at the end of this email and try it out). > > > > kse threads on amd64 doesn't work with gnome. It crashes applications > > here and there. gnome-terminal is essentially unusable. > > > > I strongly believe this to be a binding issue. I've examined rtld and > > I'm satisfied that it is behaving appropriately, so I took a long hard > > look at how FreeBSD has implemented the pthread interface, how it is > > being used, and how people expect it to behave. > [...] > > Your patch looks useful in its own right, but GNOME, Firefox, Mozilla > and XMMS have not crashed once for me since I fixed context restoring in > libpthread on amd64. Strong references cannot possibly make the old > version of context.S work correctly. > > I would be interested in hearing whether you still have problems with > libpthread and GNOME after updating your system, both with and without > nss_ldap. Great, Tim! I did indeed get this fix when testing my changes. The patch I posted still has some redeeming value, but yours was the key to gnome stability for me as well. Sean From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 04:32:05 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 510A016A4CE; Tue, 8 Jun 2004 04:32:05 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBFA743D5C; Tue, 8 Jun 2004 04:32:04 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i584W1tD015956; Tue, 8 Jun 2004 00:32:04 -0400 (EDT) Date: Tue, 8 Jun 2004 00:32:01 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:32:05 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. Please stop spamming multiple lists. No, I don't want to litter all our thread libraries with strong references. As I've said before, build your shared libraries correctly so they don't bring in the threads library. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 04:48:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF95416A4D5; Tue, 8 Jun 2004 04:48:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0A3243D45; Tue, 8 Jun 2004 04:48:45 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i584mjND047596; Mon, 7 Jun 2004 23:48:45 -0500 (CDT) (envelope-from dan) Date: Mon, 7 Jun 2004 23:48:45 -0500 From: Dan Nelson To: Daniel Eischen Message-ID: <20040608044844.GA89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:48:47 -0000 In the last episode (Jun 08), Daniel Eischen said: > No, I don't want to litter all our thread libraries with strong > references. As I've said before, build your shared libraries > correctly so they don't bring in the threads library. A good addition to bsd.port.mk, right next to the "possible network server" etc checks, might be to run ldd on all installed shared libraries and print a warning if any threads libraries show up. There are a huge number of ports that install shlibs linked to libpthreads. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:13:38 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D791F16A4D0; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106143D46; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585CdRw096687; Tue, 8 Jun 2004 01:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4faQEVN185PHyZKJ00vz" Organization: MarcusCom, Inc. Message-Id: <1086671609.18374.18.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:13:29 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:13:38 -0000 --=-4faQEVN185PHyZKJ00vz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: >=20 > >=20 > > Up front, I'd like to make a few apologies: > >=20 > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfull= y > > have to disagree. This email will hopefully strengthen my position. >=20 > Please stop spamming multiple lists. >=20 > No, I don't want to litter all our thread libraries with strong reference= s. > As I've said before, build your shared libraries correctly so they don't > bring in the threads library. In order to do this, I'm a strong proponent of making -pthread the default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in all cases, and reduces diffs among branches. What is keeping this from happening from a threading standpoint? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4faQEVN185PHyZKJ00vz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxUr5b2iPiv4Uz4cRAm8EAKCNndWyv3S5K6+bTsCc+F6MkQIyJgCgksgJ 4S+uSdmI4eKIGyXUUEbBDcs= =1kPV -----END PGP SIGNATURE----- --=-4faQEVN185PHyZKJ00vz-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:13:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 296BF16A4CE; Tue, 8 Jun 2004 05:13:51 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0792643D2D; Tue, 8 Jun 2004 05:13:50 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 1ECFF6AA57; Tue, 8 Jun 2004 15:13:48 +1000 (EST) Date: Tue, 8 Jun 2004 15:13:47 +1000 From: John Birrell To: Dan Nelson Message-ID: <20040608051347.GA3604@freebsd3.cimlogic.com.au> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608044844.GA89198@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i cc: ports@freebsd.org cc: freebsd-threads@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:13:51 -0000 [ cross-post lists cut back, ports added 8-) ] On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > A good addition to bsd.port.mk, right next to the "possible network > server" etc checks, might be to run ldd on all installed shared > libraries and print a warning if any threads libraries show up. There > are a huge number of ports that install shlibs linked to libpthreads. Good idea. -- John Birrell From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:21:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A1A316A4CE; Tue, 8 Jun 2004 05:21:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C833543D54; Tue, 8 Jun 2004 05:21:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i585NvTj001259; Mon, 7 Jun 2004 23:23:58 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C54CC4.8090602@freebsd.org> Date: Mon, 07 Jun 2004 23:21:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <1086671609.18374.18.camel@shumai.marcuscom.com> In-Reply-To: <1086671609.18374.18.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:21:42 -0000 Joe Marcus Clarke wrote: > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >>On Mon, 7 Jun 2004, Sean McNeil wrote: >> >> >>>Up front, I'd like to make a few apologies: >>> >>>1) I am sorry for the length of this email. >>>2) Although some very valid opinions have been expressed, I respectfully >>>have to disagree. This email will hopefully strengthen my position. >> >>Please stop spamming multiple lists. >> >>No, I don't want to litter all our thread libraries with strong references. >>As I've said before, build your shared libraries correctly so they don't >>bring in the threads library. > > > In order to do this, I'm a strong proponent of making -pthread the > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > all cases, and reduces diffs among branches. What is keeping this from > happening from a threading standpoint? > > Joe > If you're going to change default behaviour like this then you need to do it before 5.3 and live with the change for the entire life of 5.x. I oppose changing it in 4.x. Scott From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:23:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 928EF16A4CE for ; Tue, 8 Jun 2004 05:23:51 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EDE43D1F for ; Tue, 8 Jun 2004 05:23:51 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i585NotD027499; Tue, 8 Jun 2004 01:23:50 -0400 (EDT) Date: Tue, 8 Jun 2004 01:23:50 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Joe Marcus Clarke In-Reply-To: <1086671609.18374.18.camel@shumai.marcuscom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:23:51 -0000 [ trimmed to threads@ ] On Tue, 8 Jun 2004, Joe Marcus Clarke wrote: > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > > > > > > Up front, I'd like to make a few apologies: > > > > > > 1) I am sorry for the length of this email. > > > 2) Although some very valid opinions have been expressed, I respectfully > > > have to disagree. This email will hopefully strengthen my position. > > > > Please stop spamming multiple lists. > > > > No, I don't want to litter all our thread libraries with strong references. > > As I've said before, build your shared libraries correctly so they don't > > bring in the threads library. > > In order to do this, I'm a strong proponent of making -pthread the > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > all cases, and reduces diffs among branches. What is keeping this from > happening from a threading standpoint? Nothing from what I can see. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:24:56 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5D816A4CE; Tue, 8 Jun 2004 05:24:56 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D5343D45; Tue, 8 Jun 2004 05:24:55 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585Nvel096804; Tue, 8 Jun 2004 01:23:57 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Scott Long In-Reply-To: <40C54CC4.8090602@freebsd.org> References: <1086671609.18374.18.camel@shumai.marcuscom.com> <40C54CC4.8090602@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BHBN6it8T3voSfmtqZO4" Organization: MarcusCom, Inc. Message-Id: <1086672287.18374.22.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:24:47 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:24:56 -0000 --=-BHBN6it8T3voSfmtqZO4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 01:21, Scott Long wrote: > Joe Marcus Clarke wrote: > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >=20 > >>On Mon, 7 Jun 2004, Sean McNeil wrote: > >> > >> > >>>Up front, I'd like to make a few apologies: > >>> > >>>1) I am sorry for the length of this email. > >>>2) Although some very valid opinions have been expressed, I respectful= ly > >>>have to disagree. This email will hopefully strengthen my position. > >> > >>Please stop spamming multiple lists. > >> > >>No, I don't want to litter all our thread libraries with strong referen= ces. > >>As I've said before, build your shared libraries correctly so they don'= t > >>bring in the threads library. > >=20 > >=20 > > In order to do this, I'm a strong proponent of making -pthread the > > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > > all cases, and reduces diffs among branches. What is keeping this from > > happening from a threading standpoint? > >=20 > > Joe > >=20 >=20 > If you're going to change default behaviour like this then you need to > do it before 5.3 and live with the change for the entire life of 5.x. > I oppose changing it in 4.x. Right, this would only be a change for 5.X, and would make it identical to 4.X. -pthread works for 5.X right now, and will link executables to libpthread. Shared objects will only use libpthread to resolve symbols at link-time. Joe >=20 > Scott --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-BHBN6it8T3voSfmtqZO4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxU2fb2iPiv4Uz4cRAqf5AJ9SfU4UTuiLp7I2I3Etf47S465qogCfRYdO O0S9uJCFTifzADBw6cK3euE= =IIbB -----END PGP SIGNATURE----- --=-BHBN6it8T3voSfmtqZO4-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:25:25 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75AC616A4CE for ; Tue, 8 Jun 2004 05:25:25 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1617443D58 for ; Tue, 8 Jun 2004 05:25:25 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i585PKtD027778; Tue, 8 Jun 2004 01:25:20 -0400 (EDT) Date: Tue, 8 Jun 2004 01:25:20 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Nelson In-Reply-To: <20040608044844.GA89198@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:25:25 -0000 [ trimmed to threads@ ] On Mon, 7 Jun 2004, Dan Nelson wrote: > In the last episode (Jun 08), Daniel Eischen said: > > No, I don't want to litter all our thread libraries with strong > > references. As I've said before, build your shared libraries > > correctly so they don't bring in the threads library. > > A good addition to bsd.port.mk, right next to the "possible network > server" etc checks, might be to run ldd on all installed shared > libraries and print a warning if any threads libraries show up. There > are a huge number of ports that install shlibs linked to libpthreads. Sure, go ahead. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:34:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0702616A4CE; Tue, 8 Jun 2004 05:34:42 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C24143D45; Tue, 8 Jun 2004 05:34:41 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i585YXtD029581; Tue, 8 Jun 2004 01:34:33 -0400 (EDT) Date: Tue, 8 Jun 2004 01:34:33 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Birrell In-Reply-To: <20040608051347.GA3604@freebsd3.cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: ports@freebsd.org cc: Dan Nelson cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:34:42 -0000 On Tue, 8 Jun 2004, John Birrell wrote: > [ cross-post lists cut back, ports added 8-) ] > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > A good addition to bsd.port.mk, right next to the "possible network > > server" etc checks, might be to run ldd on all installed shared > > libraries and print a warning if any threads libraries show up. There > > are a huge number of ports that install shlibs linked to libpthreads. > > Good idea. Just picking a message at random to reply to... In case anyone wonders why we don't use strong references, I chose to mimic what Solaris does: bash-2.05$ nm /lib/libpthread.so.1 | grep pthread_mutex_lock 0000000000003c80 T _pthread_mutex_lock 0000000000003c80 W pthread_mutex_lock bash-2.05$ nm /lib/libc.so.1 | grep pthread_mutex_lock 0000000000096c38 W _pthread_mutex_lock 0000000000096c38 W pthread_mutex_lock It is also easy to provide your own version of pthread_foo() without having any strong references override it. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 05:41:29 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 431D116A4CE; Tue, 8 Jun 2004 05:41:29 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C64F143D48; Tue, 8 Jun 2004 05:41:28 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id AB3A66AA57; Tue, 8 Jun 2004 15:41:27 +1000 (EST) Date: Tue, 8 Jun 2004 15:41:27 +1000 From: John Birrell To: Daniel Eischen Message-ID: <20040608054127.GB3604@freebsd3.cimlogic.com.au> References: <20040608051347.GA3604@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: ports@freebsd.org cc: Dan Nelson cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:41:29 -0000 On Tue, Jun 08, 2004 at 01:34:33AM -0400, Daniel Eischen wrote: > On Tue, 8 Jun 2004, John Birrell wrote: > > > [ cross-post lists cut back, ports added 8-) ] > > > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. There > > > are a huge number of ports that install shlibs linked to libpthreads. > > > > Good idea. > > Just picking a message at random to reply to... > > In case anyone wonders why we don't use strong references, I chose to > mimic what Solaris does: > > bash-2.05$ nm /lib/libpthread.so.1 | grep pthread_mutex_lock > 0000000000003c80 T _pthread_mutex_lock > 0000000000003c80 W pthread_mutex_lock > > bash-2.05$ nm /lib/libc.so.1 | grep pthread_mutex_lock > 0000000000096c38 W _pthread_mutex_lock > 0000000000096c38 W pthread_mutex_lock > > It is also easy to provide your own version of pthread_foo() without > having any strong references override it. Despite the heat-of-the-moment on amd64, FWIW, using linpthread on i386 on a clean machine with NOLIBC_R set in /etc/make.conf, nothing in libmap.conf and just normal ports builds, gnome, mplayer, mozilla, openoffice etc work fine for me on current (except for the ACPI kernel problems which should either be fixed or backed out IMNSHO). -- John Birrell From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 06:38:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Tue, 8 Jun 2004 06:38:51 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221A043D46; Tue, 8 Jun 2004 06:38:47 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 8 Jun 2004 09:38:29 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jun 2004 08:14:06 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id F21B556C90; Tue, 8 Jun 2004 05:13:47 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6325216A4D6; Tue, 8 Jun 2004 05:13:47 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D791F16A4D0; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106143D46; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585CdRw096687; Tue, 8 Jun 2004 01:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4faQEVN185PHyZKJ00vz" Organization: MarcusCom, Inc. Message-Id: <1086671609.18374.18.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:13:29 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 08 Jun 2004 05:14:06.0507 (UTC) FILETIME=[6C04FFB0:01C44D17] cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: Sean McNeil cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:38:51 -0000 --=-4faQEVN185PHyZKJ00vz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: >=20 > >=20 > > Up front, I'd like to make a few apologies: > >=20 > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfull= y > > have to disagree. This email will hopefully strengthen my position. >=20 > Please stop spamming multiple lists. >=20 > No, I don't want to litter all our thread libraries with strong reference= s. > As I've said before, build your shared libraries correctly so they don't > bring in the threads library. In order to do this, I'm a strong proponent of making -pthread the default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in all cases, and reduces diffs among branches. What is keeping this from happening from a threading standpoint? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4faQEVN185PHyZKJ00vz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxUr5b2iPiv4Uz4cRAm8EAKCNndWyv3S5K6+bTsCc+F6MkQIyJgCgksgJ 4S+uSdmI4eKIGyXUUEbBDcs= =1kPV -----END PGP SIGNATURE----- --=-4faQEVN185PHyZKJ00vz-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 07:23:38 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E87D816A4CE; Tue, 8 Jun 2004 07:23:38 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C9643D1F; Tue, 8 Jun 2004 07:23:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i587NUqE021887; Tue, 8 Jun 2004 03:23:30 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6A0D652902; Tue, 8 Jun 2004 00:23:30 -0700 (PDT) Date: Tue, 8 Jun 2004 00:23:30 -0700 From: Kris Kennaway To: John Birrell Message-ID: <20040608072330.GA82183@xor.obsecurity.org> References: <20040608051347.GA3604@freebsd3.cimlogic.com.au> <20040608054127.GB3604@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20040608054127.GB3604@freebsd3.cimlogic.com.au> User-Agent: Mutt/1.4.2.1i cc: ports@freebsd.org cc: freebsd-threads@freebsd.org cc: Dan Nelson cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:23:39 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 08, 2004 at 03:41:27PM +1000, John Birrell wrote: > On Tue, Jun 08, 2004 at 01:34:33AM -0400, Daniel Eischen wrote: > > On Tue, 8 Jun 2004, John Birrell wrote: > >=20 > > > [ cross-post lists cut back, ports added 8-) ] > > >=20 > > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > > A good addition to bsd.port.mk, right next to the "possible network > > > > server" etc checks, might be to run ldd on all installed shared > > > > libraries and print a warning if any threads libraries show up. Th= ere > > > > are a huge number of ports that install shlibs linked to libpthread= s. > > >=20 > > > Good idea. > >=20 > > Just picking a message at random to reply to... > >=20 > > In case anyone wonders why we don't use strong references, I chose to > > mimic what Solaris does: > >=20 > > bash-2.05$ nm /lib/libpthread.so.1 | grep pthread_mutex_lock > > 0000000000003c80 T _pthread_mutex_lock > > 0000000000003c80 W pthread_mutex_lock > >=20 > > bash-2.05$ nm /lib/libc.so.1 | grep pthread_mutex_lock > > 0000000000096c38 W _pthread_mutex_lock > > 0000000000096c38 W pthread_mutex_lock > >=20 > > It is also easy to provide your own version of pthread_foo() without > > having any strong references override it. >=20 > Despite the heat-of-the-moment on amd64, FWIW, using linpthread on i386 > on a clean machine with NOLIBC_R set in /etc/make.conf, nothing in libmap= .conf > and just normal ports builds, gnome, mplayer, mozilla, openoffice etc work > fine for me on current (except for the ACPI kernel problems which should > either be fixed or backed out IMNSHO). Yeah, some time last year I went through and fixed or marked BROKEN all the ports that link explicitly to libc_r, and I think they've all been fixed to use PTHREAD_LIBS. Kris --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWlyWry0BWjoQKURAsj6AJ0QnxMzXMhvgv3/xYy4yYS1ZmOWTgCfbRvK za48KdtyUiXT3yDIpvIFw1U= =1lNE -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 07:27:10 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1889116A4CE; Tue, 8 Jun 2004 07:27:10 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C2143D45; Tue, 8 Jun 2004 07:27:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i587R7qE022779; Tue, 8 Jun 2004 03:27:07 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D6D5651955; Tue, 8 Jun 2004 00:27:06 -0700 (PDT) Date: Tue, 8 Jun 2004 00:27:06 -0700 From: Kris Kennaway To: Dan Nelson Message-ID: <20040608072706.GA82243@xor.obsecurity.org> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20040608044844.GA89198@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:27:10 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > In the last episode (Jun 08), Daniel Eischen said: > > No, I don't want to litter all our thread libraries with strong > > references. As I've said before, build your shared libraries > > correctly so they don't bring in the threads library. >=20 > A good addition to bsd.port.mk, right next to the "possible network > server" etc checks, might be to run ldd on all installed shared > libraries and print a warning if any threads libraries show up. There > are a huge number of ports that install shlibs linked to libpthreads. Some of these are probably correct, in that the library started using libpthreads internally and there are a large number of clients that would otherwise need to be changed to link to that library. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWpKWry0BWjoQKURAn+6AJ46khXPmJulpz485nM4Xb2p43vargCdFEma OpAqGmYFBmYWVAdxb7FFKgk= =yXEK -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 07:40:48 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6105C16A4CE; Tue, 8 Jun 2004 07:40:48 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3916F43D48; Tue, 8 Jun 2004 07:40:48 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6B6E6FD031; Tue, 8 Jun 2004 00:40:47 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00672-01; Tue, 8 Jun 2004 00:40:46 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 96446FD02E; Tue, 8 Jun 2004 00:40:46 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086680446.1060.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 00:40:46 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: ports@freebsd.org cc: Dan Nelson cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:40:48 -0000 On Mon, 2004-06-07 at 22:34, Daniel Eischen wrote: > On Tue, 8 Jun 2004, John Birrell wrote: > > > [ cross-post lists cut back, ports added 8-) ] > > > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. There > > > are a huge number of ports that install shlibs linked to libpthreads. > > > > Good idea. > > Just picking a message at random to reply to... > > In case anyone wonders why we don't use strong references, I chose to > mimic what Solaris does: > > bash-2.05$ nm /lib/libpthread.so.1 | grep pthread_mutex_lock > 0000000000003c80 T _pthread_mutex_lock > 0000000000003c80 W pthread_mutex_lock > > bash-2.05$ nm /lib/libc.so.1 | grep pthread_mutex_lock > 0000000000096c38 W _pthread_mutex_lock > 0000000000096c38 W pthread_mutex_lock > > It is also easy to provide your own version of pthread_foo() without > having any strong references override it. OK, that is what I was wondering. In that case, you have failed to mimic Solaris: [sean@wrsparc sean]$ uname -a SunOS wrsparc.mcneil.com 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-5_10 [sean@wrsparc sean]$ nm /lib/libpthread.so.1 | grep select [201] | 21328| 8|FUNC |GLOB |0 |8 |select [sean@wrsparc sean]$ nm /lib/libc.so.1 | grep select [213] | 320732| 1420|FUNC |LOCL |0 |12 |_libc_select [4534] | 320732| 1420|FUNC |GLOB |0 |12 |_select [3556] | 320732| 1420|FUNC |WEAK |0 |12 |select [1385] | 0| 0|FILE |LOCL |0 |ABS |select.c [4404] | 322152| 1920|FUNC |GLOB |0 |12 |select_large_fdset [1387] | 0| 0|FILE |LOCL |0 |ABS |select_large_fdset.c Same thing with open or any of the other libc functions. That is why Solaris works correctly and FreeBSD does not. From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 08:06:11 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55ED016A4CE for ; Tue, 8 Jun 2004 08:06:11 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 487C143D49 for ; Tue, 8 Jun 2004 08:06:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <20040608080555011001arhse>; Tue, 8 Jun 2004 08:05:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA36692; Tue, 8 Jun 2004 01:05:56 -0700 (PDT) Date: Tue, 8 Jun 2004 01:05:55 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Joe Marcus Clarke cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 08:06:11 -0000 On Tue, 8 Jun 2004, Daniel Eischen wrote: > [ trimmed to threads@ ] > > On Tue, 8 Jun 2004, Joe Marcus Clarke wrote: > > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > > > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > > > > > > > > > Up front, I'd like to make a few apologies: > > > > > > > > 1) I am sorry for the length of this email. > > > > 2) Although some very valid opinions have been expressed, I respectfully > > > > have to disagree. This email will hopefully strengthen my position. > > > > > > Please stop spamming multiple lists. > > > > > > No, I don't want to litter all our thread libraries with strong references. > > > As I've said before, build your shared libraries correctly so they don't > > > bring in the threads library. Can you explain to me in words of 1 sylable why libpthread should not have strong symbols? I haven't been following this argument.. > > > > In order to do this, I'm a strong proponent of making -pthread the > > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > > all cases, and reduces diffs among branches. What is keeping this from > > happening from a threading standpoint? > > Nothing from what I can see. > > -- > Dan Eischen > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 15:30:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5900116A4D1; Tue, 8 Jun 2004 15:30:22 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i58FULKt045926; Tue, 8 Jun 2004 11:30:21 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i58FUF4V045925; Tue, 8 Jun 2004 11:30:15 -0400 (EDT) (envelope-from green) Date: Tue, 8 Jun 2004 11:30:14 -0400 From: Brian Feldman To: Kris Kennaway Message-ID: <20040608153014.GE23083@green.homeunix.org> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608072706.GA82243@xor.obsecurity.org> User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: Dan Nelson cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 15:30:23 -0000 On Tue, Jun 08, 2004 at 12:27:06AM -0700, Kris Kennaway wrote: > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > In the last episode (Jun 08), Daniel Eischen said: > > > No, I don't want to litter all our thread libraries with strong > > > references. As I've said before, build your shared libraries > > > correctly so they don't bring in the threads library. > > > > A good addition to bsd.port.mk, right next to the "possible network > > server" etc checks, might be to run ldd on all installed shared > > libraries and print a warning if any threads libraries show up. There > > are a huge number of ports that install shlibs linked to libpthreads. > > Some of these are probably correct, in that the library started using > libpthreads internally and there are a large number of clients that > would otherwise need to be changed to link to that library. In this case, Berkeley DB 4.2 actually doesn't even compile in pthreads support (which it would use exclusively for mutexes); since it compiles in "test-and-set" mutex support, the linking to -lpthread is 100% bogus. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 15:45:12 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9287F16A4CE; Tue, 8 Jun 2004 15:45:12 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45BEB43D55; Tue, 8 Jun 2004 15:45:12 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i58FjB58020252; Tue, 8 Jun 2004 10:45:11 -0500 (CDT) (envelope-from dan) Date: Tue, 8 Jun 2004 10:45:11 -0500 From: Dan Nelson To: Kris Kennaway Message-ID: <20040608154510.GB89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20040608072706.GA82243@xor.obsecurity.org> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 15:45:12 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Jun 08), Kris Kennaway said: > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > In the last episode (Jun 08), Daniel Eischen said: > > > No, I don't want to litter all our thread libraries with strong > > > references. As I've said before, build your shared libraries > > > correctly so they don't bring in the threads library. > > > > A good addition to bsd.port.mk, right next to the "possible network > > server" etc checks, might be to run ldd on all installed shared > > libraries and print a warning if any threads libraries show up. There > > are a huge number of ports that install shlibs linked to libpthreads. > > Some of these are probably correct, in that the library started using > libpthreads internally and there are a large number of clients that > would otherwise need to be changed to link to that library. I don't think you can have it both ways, though. The rule is either "pthreads-using shared libraries should pull in a pthreads lib themselves" or "programs wanting to link to pthreads-using shared libraries should link with a pthreads lib". Attached are patches to add this check to the security-check target. Ideally they would be checked separately or flagged as something other than security problems, but that would require copying security-check.awk and a larger diff.. -- Dan Nelson dnelson@allantgroup.com --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pthreadscheck.diff" Index: Mk/bsd.port.mk =================================================================== RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v retrieving revision 1.490 diff -u -r1.490 bsd.port.mk --- Mk/bsd.port.mk 31 May 2004 18:07:57 -0000 1.490 +++ Mk/bsd.port.mk 8 Jun 2004 14:59:04 -0000 @@ -3334,10 +3334,11 @@ # 1. setugid files # 2. accept()/recvfrom() which indicates network listening capability # 3. insecure functions (gets/mktemp/tempnam/[XXX]) -# 4. startup scripts, in conjunction with 2. -# 5. world-writable files/dirs +# 4. shared libs linked directly to pthreads libs +# 5. startup scripts, in conjunction with 2. +# 6. world-writable files/dirs # - -@${RM} -f ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable ${WRKDIR}/.PLIST.objdump; \ + -@${RM} -f ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.ldd; \ ${AWK} -v prefix='${PREFIX}' ' \ match($$0, /^@cwd /) { prefix = substr($$0, RSTART + RLENGTH); next; } \ /^@/ { next; } \ @@ -3351,9 +3352,12 @@ ${TR} '\n' '\0' < ${WRKDIR}/.PLIST.flattened \ | ${XARGS} -0 -J % ${FIND} % -prune ! -type l -type f -print0 2> /dev/null \ | ${XARGS} -0 -n 1 /usr/bin/objdump -R 2> /dev/null > ${WRKDIR}/.PLIST.objdump; \ + ${GREP} '\.so' < ${WRKDIR}/.PLIST.flattened | ${TR} '\n' '\0' \ + | ${XARGS} -0 -J % ${FIND} % -prune ! -type l -type f -print0 2> /dev/null \ + | ${XARGS} -0 -n 1 /usr/bin/ldd -a 2> /dev/null > ${WRKDIR}/.PLIST.ldd; \ if \ ! ${AWK} -v audit="$${PORTS_AUDIT}" -f ${PORTSDIR}/Tools/scripts/security-check.awk \ - ${WRKDIR}/.PLIST.flattened ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable; \ + ${WRKDIR}/.PLIST.flattened ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.ldd ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable; \ then \ www_site=$$(cd ${.CURDIR} && ${MAKE} ${__softMAKEFLAGS} www-site); \ if [ ! -z "$${www_site}" ]; then \ Index: Tools/scripts/security-check.awk =================================================================== RCS file: /home/ncvs/ports/Tools/scripts/security-check.awk,v retrieving revision 1.1 diff -u -r1.1 security-check.awk --- Tools/scripts/security-check.awk 19 Jan 2004 22:19:00 -0000 1.1 +++ Tools/scripts/security-check.awk 8 Jun 2004 14:38:09 -0000 @@ -9,6 +9,7 @@ split("", setuid_binaries); split("", writable_files); split("", startup_scripts); + split("", pthreads_libs); header_printed = 0; } FILENAME ~ /\.flattened$/ { @@ -18,7 +19,6 @@ FILENAME ~ /\.objdump$/ { if (match($0, /: +file format [^ ]+$/)) { file = substr($0, 1, RSTART - 1); - stupid_functions = ""; next; } if (file == "") @@ -29,6 +29,16 @@ if ($3 ~ /^(accept|recvfrom)$/) network_binaries[file] = 1; } +FILENAME ~ /\.ldd$/ { + if (match($0, /:$/)) { + file = substr($0, 1, RSTART - 1); + next; + } + if (file == "") + next; + if ($1 ~ /^(libc_r|libpthread|libthr).so/) + pthreads_libs[file] = $3; +} FILENAME ~ /\.setuid$/ { setuid_binaries[$0] = 1; } FILENAME ~ /\.writable$/ { writable_files[$0] = 1; } function print_header() { @@ -79,6 +89,20 @@ if (note_printed) print ""; } + + note_printed = 0; + for (file in pthreads_libs) { + if (!note_printed) { + print_header(); + print " This port has installed the following shared libraries which are"; + print " incorrectly linked to a pthreads shared library."; + note_printed = 1; + } + printf "%s (linked to %s)\n", file, pthreads_libs[file]; + } + if (note_printed) + print ""; + note_printed = 0; for (file in writable_files) { if (!note_printed) { --zYM0uCDKw75PZbzx-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 16:55:08 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89DAF16A4CE for ; Tue, 8 Jun 2004 16:55:08 +0000 (GMT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 389B343D45 for ; Tue, 8 Jun 2004 16:55:07 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h86.vuokselantie10.fi [193.64.42.134]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i58Gsu3v021371 for ; Tue, 8 Jun 2004 19:54:56 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40C5EF60.5040409@he.iki.fi> Date: Tue, 08 Jun 2004 19:54:56 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: profiling applications with threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 16:55:08 -0000 I´m wondering if anyone would offer me advice in between the symbol resolving + amd64 discussion if there is something inherently known to be broken with 5.2.1 so profiling threaded applications is not supported and if there are patches that could solve the almost immediate coredumps? Pete From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 17:01:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD5A16A4CE for ; Tue, 8 Jun 2004 17:01:44 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C090843D2F for ; Tue, 8 Jun 2004 17:01:43 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i58H1WPd005184; Tue, 8 Jun 2004 13:01:32 -0400 (EDT) Date: Tue, 8 Jun 2004 13:01:32 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Nelson In-Reply-To: <20040608154510.GB89198@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: Sean McNeil cc: Kris Kennaway Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 17:01:44 -0000 On Tue, 8 Jun 2004, Dan Nelson wrote: > In the last episode (Jun 08), Kris Kennaway said: > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > In the last episode (Jun 08), Daniel Eischen said: > > > > No, I don't want to litter all our thread libraries with strong > > > > references. As I've said before, build your shared libraries > > > > correctly so they don't bring in the threads library. > > > > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. There > > > are a huge number of ports that install shlibs linked to libpthreads. > > > > Some of these are probably correct, in that the library started using > > libpthreads internally and there are a large number of clients that > > would otherwise need to be changed to link to that library. > > I don't think you can have it both ways, though. The rule is either > "pthreads-using shared libraries should pull in a pthreads lib > themselves" or "programs wanting to link to pthreads-using shared > libraries should link with a pthreads lib". I think there are two cases as I outlined earlier in this thread: a) libraries use pthread_foo() for thread-safety b) libraries use pthread_create() & pthread_foo() to create and manage threads on behalf of the application (e.g, an AIO library). I doubt there are many, if any, of b). If there are, you should require that all applications that use b) also link to the threads library (which makes sense because they are then threaded). For a), applications can choose to link with the threads library or not, and it doesn't matter at all that the shared library is not linked to the threads library. Also for b), if the library is not linked to the threads library and the application using b) also does not link to the threads library, then you get a link error for the application (missing pthread_foo symbols). It should be immediately obvious when building the port what happened. Another advantage of not linking shared libraries to a threads library is that it becomes much easier to tailor a libmap.conf on per-application basis. You no longer have to worry about shared libraries bringing in a different thread library. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 17:07:20 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EFC416A4CE for ; Tue, 8 Jun 2004 17:07:20 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F68543D39 for ; Tue, 8 Jun 2004 17:07:20 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i58H70Pd006391; Tue, 8 Jun 2004 13:07:00 -0400 (EDT) Date: Tue, 8 Jun 2004 13:07:00 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <40C5EF60.5040409@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: profiling applications with threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 17:07:20 -0000 On Tue, 8 Jun 2004, Petri Helenius wrote: >=20 > I=B4m wondering if anyone would offer me advice in between the symbol=20 > resolving + amd64 discussion if there is something inherently known to=20 > be broken with 5.2.1 so profiling threaded applications is not supported= =20 > and if there are patches that could solve the almost immediate coredumps? I don't know about 5.2.1, but there are bugs in libkse in that release. If you are having problems, I would first suggest -current. I built and ran simple applications with -pg using libpthread in current, but haven't tried analyzing them. --=20 Dan From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 17:57:24 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F13716A4CE; Tue, 8 Jun 2004 17:57:24 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8CB443D2D; Tue, 8 Jun 2004 17:57:23 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i58HuMZm003561; Tue, 8 Jun 2004 13:56:22 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Dan Nelson In-Reply-To: <20040608154510.GB89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> <20040608154510.GB89198@dan.emsphone.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FnZVoL0BYwSU0eYirIzC" Organization: MarcusCom, Inc. Message-Id: <1086717435.68846.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 13:57:16 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 17:57:24 -0000 --=-FnZVoL0BYwSU0eYirIzC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 11:45, Dan Nelson wrote: > In the last episode (Jun 08), Kris Kennaway said: > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > In the last episode (Jun 08), Daniel Eischen said: > > > > No, I don't want to litter all our thread libraries with strong > > > > references. As I've said before, build your shared libraries > > > > correctly so they don't bring in the threads library. > > >=20 > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. Ther= e > > > are a huge number of ports that install shlibs linked to libpthreads. > >=20 > > Some of these are probably correct, in that the library started using > > libpthreads internally and there are a large number of clients that > > would otherwise need to be changed to link to that library. >=20 > I don't think you can have it both ways, though. The rule is either > "pthreads-using shared libraries should pull in a pthreads lib > themselves" or "programs wanting to link to pthreads-using shared > libraries should link with a pthreads lib". >=20 > Attached are patches to add this check to the security-check target.=20 > Ideally they would be checked separately or flagged as something other > than security problems, but that would require copying > security-check.awk and a larger diff.. If we switched PTHREAD_LIBS to -pthread, we wouldn't need this. Shared objects would not have a link to libpthread, and shared objects that really referenced pthread symbols would still require executables to be linked to PTHREAD_LIBS (i.e. how it works on 4.X). Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-FnZVoL0BYwSU0eYirIzC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxf37b2iPiv4Uz4cRAmjEAJ9eZKBGVjPP0j7K+IPemwL49iNo7gCfVmGb 7LWrJiKxUkm7wAmN+o44+A0= =fnCz -----END PGP SIGNATURE----- --=-FnZVoL0BYwSU0eYirIzC-- From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 19:00:54 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F7E216A4CE for ; Tue, 8 Jun 2004 19:00:54 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C8443D53 for ; Tue, 8 Jun 2004 19:00:52 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id E3C5CFD03A; Tue, 8 Jun 2004 12:00:51 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36801-09; Tue, 8 Jun 2004 12:00:51 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 60290FD031; Tue, 8 Jun 2004 12:00:51 -0700 (PDT) From: Sean McNeil To: Julian Elischer In-Reply-To: References: Content-Type: text/plain Message-Id: <1086721251.44183.14.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 12:00:51 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Joe Marcus Clarke cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 19:00:54 -0000 On Tue, 2004-06-08 at 01:05, Julian Elischer wrote: > On Tue, 8 Jun 2004, Daniel Eischen wrote: > > > [ trimmed to threads@ ] > > > > On Tue, 8 Jun 2004, Joe Marcus Clarke wrote: > > > > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > > > > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > > > > > > > > > > > > Up front, I'd like to make a few apologies: > > > > > > > > > > 1) I am sorry for the length of this email. > > > > > 2) Although some very valid opinions have been expressed, I respectfully > > > > > have to disagree. This email will hopefully strengthen my position. > > > > > > > > Please stop spamming multiple lists. > > > > > > > > No, I don't want to litter all our thread libraries with strong references. > > > > As I've said before, build your shared libraries correctly so they don't > > > > bring in the threads library. > > Can you explain to me in words of 1 sylable why libpthread should not > have strong symbols? I haven't been following this argument.. As far as I can tell, there is no good reason. So far, there has been a lot of talk about how to deal with threading because of this very issue. Here is how threads were designed to work on all other platforms: If a shared library wants to be thread-safe, they include CFLAGS definitions for any include file magic that may have to be done. They do not link the shared library to the libpthread library. If a shared library is using threads (create, join, etc.) then they still do the CFLAGS defs but they also link to the pthread library. An application would link to the libraries they desire to use. They don't care if some library they use pulls in pthread or not. They only care when the application itself uses threads. If it is a direct library dependency, the linker would make the application depend on pthread. For instance, libORBit02.so.0 might be used by a gnome application, but it doesn't need to know or care that ORBit uses threads. libc functions should be global symbols in libpthread that override the functionality usually provided by libc. I fail to see why this is opposed by the FreeBSD community, the reasons behind the opposition, or why this entire thread has started trying to work around the mistake of making them weak symbols instead of just fixing the underlying problem by making them strong references. Sean From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 19:15:40 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20BE316A4D0 for ; Tue, 8 Jun 2004 19:15:40 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8F6243D41 for ; Tue, 8 Jun 2004 19:15:39 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i58JFYPd008611; Tue, 8 Jun 2004 15:15:34 -0400 (EDT) Date: Tue, 8 Jun 2004 15:15:34 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086721251.44183.14.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Joe Marcus Clarke cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 19:15:40 -0000 On Tue, 8 Jun 2004, Sean McNeil wrote: > As far as I can tell, there is no good reason. So far, there has been a > lot of talk about how to deal with threading because of this very > issue. Here is how threads were designed to work on all other > platforms: > > If a shared library wants to be thread-safe, they include CFLAGS > definitions for any include file magic that may have to be done. They > do not link the shared library to the libpthread library. This is wrong. Most of the shared libraries in ports only want to be thread-safe, yet they still link to libpthread. > If a shared library is using threads (create, join, etc.) then they > still do the CFLAGS defs but they also link to the pthread library. There are not many (if any) of these libraries, but if there are, then applications using those libraries should link to the threads library of their choice. > An application would link to the libraries they desire to use. They > don't care if some library they use pulls in pthread or not. They only They should care, especially since you can choose different thread libraries. > care when the application itself uses threads. If it is a direct > library dependency, the linker would make the application depend on > pthread. For instance, libORBit02.so.0 might be used by a gnome > application, but it doesn't need to know or care that ORBit uses > threads. > > libc functions should be global symbols in libpthread that override the > functionality usually provided by libc. > > I fail to see why this is opposed by the FreeBSD community, the reasons > behind the opposition, or why this entire thread has started trying to > work around the mistake of making them weak symbols instead of just > fixing the underlying problem by making them strong references. Because there is no problem if you link correctly. And I would like to be able to override libc functions with my own. I wish malloc was weak. I wish all our exported symbols were weak. See my earlier email for the advantage of not having shared libraries linked to thread libraries (easier usage of libmap.conf). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 19:58:52 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B42E16A4CE; Tue, 8 Jun 2004 19:58:52 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2631143D39; Tue, 8 Jun 2004 19:58:52 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i58JwpD0027730; Tue, 8 Jun 2004 14:58:51 -0500 (CDT) (envelope-from dan) Date: Tue, 8 Jun 2004 14:58:50 -0500 From: Dan Nelson To: Joe Marcus Clarke Message-ID: <20040608195850.GB46338@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> <20040608154510.GB89198@dan.emsphone.com> <1086717435.68846.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086717435.68846.9.camel@shumai.marcuscom.com> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 19:58:52 -0000 In the last episode (Jun 08), Joe Marcus Clarke said: > If we switched PTHREAD_LIBS to -pthread, we wouldn't need this. Shared > objects would not have a link to libpthread, and shared objects that > really referenced pthread symbols would still require executables to be > linked to PTHREAD_LIBS (i.e. how it works on 4.X). It'd still be a good sanity check for people porting libraries, I think. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 20:01:00 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEDBE16A4CE for ; Tue, 8 Jun 2004 20:01:00 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D07C43D48 for ; Tue, 8 Jun 2004 20:00:58 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6CC0BFD03A; Tue, 8 Jun 2004 13:00:57 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83126-02; Tue, 8 Jun 2004 13:00:56 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id BCDBFFD031; Tue, 8 Jun 2004 13:00:56 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086724856.83077.13.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 13:00:56 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Joe Marcus Clarke cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 20:01:00 -0000 On Tue, 2004-06-08 at 12:15, Daniel Eischen wrote: > On Tue, 8 Jun 2004, Sean McNeil wrote: > > As far as I can tell, there is no good reason. So far, there has been a > > lot of talk about how to deal with threading because of this very > > issue. Here is how threads were designed to work on all other > > platforms: > > > > If a shared library wants to be thread-safe, they include CFLAGS > > definitions for any include file magic that may have to be done. They > > do not link the shared library to the libpthread library. > > This is wrong. Most of the shared libraries in ports only > want to be thread-safe, yet they still link to libpthread. > > > If a shared library is using threads (create, join, etc.) then they > > still do the CFLAGS defs but they also link to the pthread library. > > There are not many (if any) of these libraries, but if there > are, then applications using those libraries should link to the > threads library of their choice. > > > An application would link to the libraries they desire to use. They > > don't care if some library they use pulls in pthread or not. They only > > They should care, especially since you can choose different > thread libraries. You are talking about two different things. With linking, they don't care as everyone should be linking to pthread when required. If the application doesn't use pthread directly, it shouldn't link with pthread. If it directly links to a library that uses pthread, then the linker will take care of that. What you are talking about is afterwards. You can select what library it uses via. libmap.conf. > > care when the application itself uses threads. If it is a direct > > library dependency, the linker would make the application depend on > > pthread. For instance, libORBit02.so.0 might be used by a gnome > > application, but it doesn't need to know or care that ORBit uses > > threads. > > > > libc functions should be global symbols in libpthread that override the > > functionality usually provided by libc. > > > > I fail to see why this is opposed by the FreeBSD community, the reasons > > behind the opposition, or why this entire thread has started trying to > > work around the mistake of making them weak symbols instead of just > > fixing the underlying problem by making them strong references. > > Because there is no problem if you link correctly. And I > would like to be able to override libc functions with my > own. I wish malloc was weak. I wish all our exported > symbols were weak. You are imposing a requirement that is not necessary. There is no reason why apache2 should have to link the main application to pthread if, for some reason, a module that you have selected requires threading. Same thing for any application that might use plugin modules. I know you have this desire to override symbols in libc. I'm not saying you can't do that. It is a security risk, but it is very useful and I would say "yes, make malloc a weak symbol". Make everything in libc weak if you want. There should be a way to enforce ownership of functions, however. pthread really needs to enforce ownership. It needs to say "I have select and use that instead of the libc version". It should not matter if libpthread was linked in a particular order. It should not matter if pthread wasn't directly linked to the application at all. If select is a strong reference, then it doesn't. I would also propose a library that enforces libc's versions of functions. One that says "I was linked in and I say libc owns this function. No one else can override it." This would be a very good security tool. > See my earlier email for the advantage of not having shared > libraries linked to thread libraries (easier usage of > libmap.conf). We are in total agreement on this when it comes to libraries that are just "thread safe" yet do not do anything thread-specific. However, it would be even more useful and reliable to be able to tell libmap.conf that "ORBit library should use libc_r" and have all applications that pull in ORBit end up with the libc_r threading library. Sean From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 20:40:21 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DED8916A4CE for ; Tue, 8 Jun 2004 20:40:21 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5D1C43D45 for ; Tue, 8 Jun 2004 20:40:21 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 73AAFFD03A; Tue, 8 Jun 2004 13:40:21 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83102-04; Tue, 8 Jun 2004 13:40:21 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id E6FE3FD031; Tue, 8 Jun 2004 13:40:20 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: <1086724856.83077.13.camel@server.mcneil.com> References: <1086724856.83077.13.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086727220.83494.10.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 13:40:20 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Joe Marcus Clarke cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 20:40:22 -0000 On Tue, 2004-06-08 at 13:00, Sean McNeil wrote: > On Tue, 2004-06-08 at 12:15, Daniel Eischen wrote: > > On Tue, 8 Jun 2004, Sean McNeil wrote: > > > I fail to see why this is opposed by the FreeBSD community, the reasons > > > behind the opposition, or why this entire thread has started trying to > > > work around the mistake of making them weak symbols instead of just > > > fixing the underlying problem by making them strong references. > > > > Because there is no problem if you link correctly. And I > > would like to be able to override libc functions with my > > own. I wish malloc was weak. I wish all our exported > > symbols were weak. By the way, you are imposing a requirement of linking pthread in a particular order to that you can override the symbols in libc (just like pthread wants to) and yet do not wish to impose a linking order on this ficticious other need you have? Why not make pthread libc overrides strong? You have made them so for things like _pthread_join, so why not for select and all those? I have an alternative proposal for you: make the libc symbols like the pthread ones.... Taking select as an example, Make libc and pthread both have weak references to __select for select. Make libc have a weak reference to __libc_select for __select. Implement __libc_select in libc and __select in pthread. Sean From owner-freebsd-threads@FreeBSD.ORG Wed Jun 9 11:21:41 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2509716A4CE; Wed, 9 Jun 2004 11:21:41 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 050C543D1F; Wed, 9 Jun 2004 11:21:41 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id EF417FD059; Wed, 9 Jun 2004 04:21:38 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80195-07; Wed, 9 Jun 2004 04:21:38 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 7B1CBFD03A; Wed, 9 Jun 2004 04:21:38 -0700 (PDT) From: Sean McNeil To: Marcel Moolenaar In-Reply-To: <20040605194113.GA26707@dhcp50.pn.xcllnt.net> References: <1086458607.18813.37.camel@server.mcneil.com> <20040605194113.GA26707@dhcp50.pn.xcllnt.net> Content-Type: text/plain Message-Id: <1086780098.95500.4.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Jun 2004 04:21:38 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: All my amd64 problems appear to be KSE X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 11:21:41 -0000 On Sat, 2004-06-05 at 12:41, Marcel Moolenaar wrote: > On Sat, Jun 05, 2004 at 03:21:29PM -0400, Daniel Eischen wrote: > > > > > > I suppose it is really libreadline at fault here and it should check > > > SA_SIGINFO. Do you think there might be others that don't check either? > > > > I don't know; perhaps. > > > > > Why doesn't this show an issue in i386? Is it just luck that info has > > > been null and not caused a bad dereference? > > > > When I write signal handlers, I usually check info and ucp to > > make sure they are not null before using them. Actually, I > > rarely use them anyways so it doesn't matter if they are null > > or not. > > Nevertheless, libpthread has a signal handler that takes 3 arguments > and it apparently gets called from other signal handlers (chaining) > that do not always pass along the full context; just the signal number > in this case. Consequently, info and ucp can be garbage as is the case > here. This is a general problem and potentionally causes failures on > all platforms, not just amd64. > > I tend to give blame to libreadline here, but I don't have a clear or > even complete picture of it all, so I might actually miss a vital > precondition that's being violated and that would clear libreadline... This really isn't libreadline's fault, but it is an issue. They should check to see if the signal hander/action has SA_SIGINFO. The problem I saw should never have happened. It came about because of a symbol binding issue. Removing an incorrect usage of libpthread by libdb41 resolved the issue. In the long run, it would be nice to fix this as there may be a time when someone installs an SA_SIGINFO handler before libreadline is initialized. Cheers, Sean From owner-freebsd-threads@FreeBSD.ORG Wed Jun 9 17:17:26 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58E6516A4CE; Wed, 9 Jun 2004 17:17:26 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3982943D49; Wed, 9 Jun 2004 17:17:26 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 03BD42A7EA; Wed, 9 Jun 2004 10:17:26 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 21F64E29E; Wed, 9 Jun 2004 10:17:24 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i59HHNTd048971; Wed, 9 Jun 2004 10:17:23 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i59HHN1P048970; Wed, 9 Jun 2004 10:17:23 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Wed, 9 Jun 2004 10:17:23 -0700 User-Agent: KMail/1.6.1 References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> In-Reply-To: <20040607215054.GA41798@cat.robbins.dropbear.id.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091017.23406.peter@wemm.org> cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 17:17:26 -0000 On Monday 07 June 2004 02:50 pm, Tim Robbins wrote: > Anyone who has resorted to using libc_r instead of libpthread on > amd64 should update their sources (ensuring they get context.S > revision 1.6), rebuild and reinstall libpthread (or world), then give > it another try. The bug I just fixed looks to have been responsible > for the mysterious crashes I was seeing in Mozilla/Firefox, XMMS and > GNOME. For what its worth, I immediately rebuild my libpthread and turned off the libmap.conf mapping I'd forgotten about, and now firefox is as stable as it was with libc_r. I ran with firefox+libc_r at home, and with libpthread at work. Now they both work reliably. Thanks a million! > > Tim > > ----- Forwarded message from "Tim J. Robbins" ----- > > From: "Tim J. Robbins" > Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > cvs-all@FreeBSD.org > Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S > X-FreeBSD-CVS-Branch: HEAD > Precedence: bulk > X-Loop: FreeBSD.ORG > X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 > > tjr 2004-06-07 21:25:16 UTC > > FreeBSD src repository > > Modified files: > lib/libpthread/arch/amd64/amd64 context.S > Log: > Avoid clobbering the red zone when running on the new context's > stack in _amd64_restore_context(). > > Revision Changes Path > 1.6 +5 -0 src/lib/libpthread/arch/amd64/amd64/context.S > > ----- End forwarded message ----- > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 03:32:31 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01ECB16A4CE for ; Fri, 11 Jun 2004 03:32:31 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D742E43D1D for ; Fri, 11 Jun 2004 03:32:30 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CA76CFD094 for ; Thu, 10 Jun 2004 20:32:14 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29626-06 for ; Thu, 10 Jun 2004 20:32:14 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 16EC7FD090 for ; Thu, 10 Jun 2004 20:32:14 -0700 (PDT) From: Sean McNeil To: freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086924733.65671.81.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 20:32:14 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 03:32:31 -0000 I'm working on kse support for gcc/gcj/gij and ran into an interesting problem with signals: Each thread installs a signal handler for synchronization. This signal handler does a sem_post() to inform it has suspended then goes into a sigsuspend() loop waiting for a signal that has no handler attached to it. So we have SIGUSR1 - signal handler attached to suspend the thread SIGUSR2 - no signal handler but waited on in sigsuspend() within the above handler. When you want to have exclusive access, you loop through and stop each thread by sending the SIGUSR2 and wait on the semaphore it posts to. Then you do your thing. When done, you signal each thread with SIGUSR2. The problem I'm seeing is that the signal handler doesn't have pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal is lost because it happens before the sigsuspend() is invoked. I think there is something missing or not functioning in sem_post that should prevent the signal handler from losing the cpu. I see there is an enter/exit critical in there. Should that prevent it from context switching? It would appear not in that exiting a critical section will cause a yield. Any help on figuring out how to fix this would be appreciated. Perhaps someone more familiar with kse can tell me how to go about changing it so that a signal handler cannot cause a yield. Perhaps something in _thr_sig_handler? TIA, Sean From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 04:19:18 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B95116A4CE for ; Fri, 11 Jun 2004 04:19:18 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04CB343D49 for ; Fri, 11 Jun 2004 04:19:18 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B4JB6x026465; Fri, 11 Jun 2004 00:19:11 -0400 (EDT) Date: Fri, 11 Jun 2004 00:19:11 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086924733.65671.81.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 04:19:18 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > I'm working on kse support for gcc/gcj/gij and ran into an interesting > problem with signals: > > Each thread installs a signal handler for synchronization. This signal > handler does a sem_post() to inform it has suspended then goes into a > sigsuspend() loop waiting for a signal that has no handler attached to > it. So we have You might want to look and see how GNAT handles synchronization between tasks; it should be merged into the gcc baseline. > SIGUSR1 - signal handler attached to suspend the thread > SIGUSR2 - no signal handler but waited on in sigsuspend() within the > above handler. Each thread has a signal handler for SIGUSR1? > When you want to have exclusive access, you loop through and stop each ^^^^ suspend? > thread by sending the SIGUSR2 and wait on the semaphore it posts to. ^^^^^^^ SIGUSR1? > Then you do your thing. When done, you signal each thread with SIGUSR2. > The problem I'm seeing is that the signal handler doesn't have > pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal > is lost because it happens before the sigsuspend() is invoked. It doesn't matter. If a signal is sent to a thread (via pthread_kill()) and that signal is masked, then the signal is added to the thread's pending signals. If it hits sigsuspend() at a later point in time and any pending signals are unmasked, then it returns after processing those pending signals. Also, don't confuse kill() with pthread_kill(). If you try to use kill(), it can go to any thread in the process whose signal is unmasked. > I think there is something missing or not functioning in sem_post that > should prevent the signal handler from losing the cpu. I see there is > an enter/exit critical in there. Should that prevent it from context > switching? It would appear not in that exiting a critical section will > cause a yield. A "thread" critical section prevents the thread from getting signals or otherwise interrupted. If the thread blocks on a low-level lock, then it will get swapped out for another thread. > Any help on figuring out how to fix this would be appreciated. Perhaps > someone more familiar with kse can tell me how to go about changing it > so that a signal handler cannot cause a yield. Perhaps something in > _thr_sig_handler? The critical section should prevent the signal handler from being invoked. Put some printf()'s in after the sem_post() and in the signal handler(). The signal handler printf()'s should always occur after the sem_post(). Plus, you shouldn't be getting that signal since it should be masked until sigsuspend() is called. Is it getting past sem_post() and into sigsuspend() or not? If it is getting past sem_post(), then I don't think that is your problem. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 04:37:21 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C327216A4CE for ; Fri, 11 Jun 2004 04:37:21 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83C8243D46 for ; Fri, 11 Jun 2004 04:37:21 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B4bG6x001697; Fri, 11 Jun 2004 00:37:18 -0400 (EDT) Date: Fri, 11 Jun 2004 00:37:16 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 04:37:21 -0000 On Fri, 11 Jun 2004, Daniel Eischen wrote: > > It doesn't matter. If a signal is sent to a thread (via pthread_kill()) > and that signal is masked, then the signal is added to the thread's > pending signals. If it hits sigsuspend() at a later point in time > and any pending signals are unmasked, then it returns after processing > those pending signals. Also be sure that the installed signal action mask is set to mask out SIGUSR2. static void sigusr1_handler(int sig, siginfo_t *info, ucontext_t *ucp) { sigset_t mask; pthread_sigmask(SIG_SETMASK, NULL, &mask); assert(sigismember(&mask, SIGUSR2) != 0); sem_post(...); sigdelset(&mask, SIGUSR2); sigsuspend(&mask); } Also I think you need a handler for SIGUSR2 as well as SIGUSR1. The default action for both SIGUSR1 and SIGUSR2 is to terminate the process. You can't set it to SIG_IGN either because that will prevent the thread from receiving the signal. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 04:41:39 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA4A816A4CE for ; Fri, 11 Jun 2004 04:41:39 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F86343D54 for ; Fri, 11 Jun 2004 04:41:39 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id B9F86FD087; Thu, 10 Jun 2004 21:41:29 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29626-09; Thu, 10 Jun 2004 21:41:29 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 12F3BFD059; Thu, 10 Jun 2004 21:41:29 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086928888.38487.18.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 21:41:28 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 04:41:39 -0000 On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > I'm working on kse support for gcc/gcj/gij and ran into an interesting > > problem with signals: > > > > Each thread installs a signal handler for synchronization. This signal > > handler does a sem_post() to inform it has suspended then goes into a > > sigsuspend() loop waiting for a signal that has no handler attached to > > it. So we have > > You might want to look and see how GNAT handles synchronization > between tasks; it should be merged into the gcc baseline. This is for boehm-gc and it works for libc_r but not for kse. > > SIGUSR1 - signal handler attached to suspend the thread > > SIGUSR2 - no signal handler but waited on in sigsuspend() within the > > above handler. > > Each thread has a signal handler for SIGUSR1? Yes, the statement below was a typo. The thread is sent the signal via pthread_kill as SIGUSR1 to suspend and SIGUSR2 to resume. > > When you want to have exclusive access, you loop through and stop each > ^^^^ suspend? > > > thread by sending the SIGUSR2 and wait on the semaphore it posts to. > ^^^^^^^ SIGUSR1? This it the typo. should be SIGUSR1. > > Then you do your thing. When done, you signal each thread with SIGUSR2. > > > The problem I'm seeing is that the signal handler doesn't have > > pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal > > is lost because it happens before the sigsuspend() is invoked. > > It doesn't matter. If a signal is sent to a thread (via pthread_kill()) > and that signal is masked, then the signal is added to the thread's > pending signals. If it hits sigsuspend() at a later point in time > and any pending signals are unmasked, then it returns after processing > those pending signals. > > Also, don't confuse kill() with pthread_kill(). If you try to > use kill(), it can go to any thread in the process whose signal > is unmasked. > > > I think there is something missing or not functioning in sem_post that > > should prevent the signal handler from losing the cpu. I see there is > > an enter/exit critical in there. Should that prevent it from context > > switching? It would appear not in that exiting a critical section will > > cause a yield. > > A "thread" critical section prevents the thread from getting > signals or otherwise interrupted. If the thread blocks on > a low-level lock, then it will get swapped out for another > thread. > > > Any help on figuring out how to fix this would be appreciated. Perhaps > > someone more familiar with kse can tell me how to go about changing it > > so that a signal handler cannot cause a yield. Perhaps something in > > _thr_sig_handler? > > The critical section should prevent the signal handler > from being invoked. Put some printf()'s in after the > sem_post() and in the signal handler(). The signal > handler printf()'s should always occur after the sem_post(). > Plus, you shouldn't be getting that signal since it > should be masked until sigsuspend() is called. > > Is it getting past sem_post() and into sigsuspend() or not? > If it is getting past sem_post(), then I don't think that is > your problem. Here is what I see: master thread calls pthread_kill with SIGUSR1 and waits on semaphore. other thread gets signal and calls sem_post. It yields the scheduler. master thread gets semaphore and continues on it's way. master thread calls pthread_kill with SIGUSR2 and keeps going. Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. other thread gets signal and calls sem_post. It yields the scheduler. master thread gets semaphore and continues on it's way. master thread calls pthread_kill with SIGUSR2 and keeps going. Finally, master scheduler is done and yields the scheduler. other thread gets to run now and then it goes into sigsuspend waiting for SIGUSR2, but it never gets it because it wasn't masked until sigsuspend is called. threads are all hung. The problem is that sem_post should not cause a reschedule of threads when inside a signal handler and it does. Cheers, Sean From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 04:55:21 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9013816A4D0 for ; Fri, 11 Jun 2004 04:55:21 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BCCA43D1D for ; Fri, 11 Jun 2004 04:55:21 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B4tJ6x005705; Fri, 11 Jun 2004 00:55:19 -0400 (EDT) Date: Fri, 11 Jun 2004 00:55:19 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086928888.38487.18.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 04:55:21 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: > > > > The critical section should prevent the signal handler > > from being invoked. Put some printf()'s in after the > > sem_post() and in the signal handler(). The signal > > handler printf()'s should always occur after the sem_post(). > > Plus, you shouldn't be getting that signal since it > > should be masked until sigsuspend() is called. > > > > Is it getting past sem_post() and into sigsuspend() or not? > > If it is getting past sem_post(), then I don't think that is > > your problem. > > Here is what I see: > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > other thread gets signal and calls sem_post. It yields the scheduler. This is fine as long as this thread doesn't get a signal until after sem_post(). Being signal safe doesn't mean that other threads can't be scheduled. > master thread gets semaphore and continues on it's way. > master thread calls pthread_kill with SIGUSR2 and keeps going. It can't keep going if there is a possibility that it can send the same thread another SIGUSR2. > Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. > other thread gets signal and calls sem_post. It yields the scheduler. Why is it getting SIGUSR1? It is waiting for SIGUSR2, not SIGUSR1. You need to mask SIGUSR1 before the sem_post() and until after the sigsuspend() on SIGUSR2. > master thread gets semaphore and continues on it's way. > master thread calls pthread_kill with SIGUSR2 and keeps going. > Finally, master scheduler is done and yields the scheduler. > other thread gets to run now and then it goes into sigsuspend waiting > for SIGUSR2, but it never gets it because it wasn't masked until > sigsuspend is called. > threads are all hung. > > The problem is that sem_post should not cause a reschedule of threads > when inside a signal handler and it does. Nope, that is allowable. Please don't confuse signal safe with "will not yield the CPU". Also, on SMP, there are not guarantees regardless! I'm not saying that there isn't a bug somewhere, but don't go reading more into what the requirements of sem_post() are. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:02:09 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7321716A4CE for ; Fri, 11 Jun 2004 05:02:09 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D00743D46 for ; Fri, 11 Jun 2004 05:02:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA90F1; Fri, 11 Jun 2004 13:01:55 +0800 Message-ID: <40C93D60.3040003@freebsd.org> Date: Fri, 11 Jun 2004 13:04:32 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086924733.65671.81.camel@server.mcneil.com> In-Reply-To: <1086924733.65671.81.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:02:09 -0000 Can you provide some code to demostrate the problem ? I have interest. David Xu Sean McNeil wrote: > I'm working on kse support for gcc/gcj/gij and ran into an interesting > problem with signals: > > Each thread installs a signal handler for synchronization. This signal > handler does a sem_post() to inform it has suspended then goes into a > sigsuspend() loop waiting for a signal that has no handler attached to > it. So we have > > SIGUSR1 - signal handler attached to suspend the thread > SIGUSR2 - no signal handler but waited on in sigsuspend() within the > above handler. > > When you want to have exclusive access, you loop through and stop each > thread by sending the SIGUSR2 and wait on the semaphore it posts to. > Then you do your thing. When done, you signal each thread with SIGUSR2. > > The problem I'm seeing is that the signal handler doesn't have > pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal > is lost because it happens before the sigsuspend() is invoked. > > I think there is something missing or not functioning in sem_post that > should prevent the signal handler from losing the cpu. I see there is > an enter/exit critical in there. Should that prevent it from context > switching? It would appear not in that exiting a critical section will > cause a yield. > > Any help on figuring out how to fix this would be appreciated. Perhaps > someone more familiar with kse can tell me how to go about changing it > so that a signal handler cannot cause a yield. Perhaps something in > _thr_sig_handler? > > TIA, > Sean > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:08:08 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6658A16A4CE for ; Fri, 11 Jun 2004 05:08:08 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 265D543D5E for ; Fri, 11 Jun 2004 05:08:08 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 91AC2FD087; Thu, 10 Jun 2004 22:08:07 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38653-01; Thu, 10 Jun 2004 22:08:07 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DEF10FD075; Thu, 10 Jun 2004 22:08:06 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086930486.38487.28.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 22:08:06 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:08:08 -0000 On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: > > > > > > The critical section should prevent the signal handler > > > from being invoked. Put some printf()'s in after the > > > sem_post() and in the signal handler(). The signal > > > handler printf()'s should always occur after the sem_post(). > > > Plus, you shouldn't be getting that signal since it > > > should be masked until sigsuspend() is called. > > > > > > Is it getting past sem_post() and into sigsuspend() or not? > > > If it is getting past sem_post(), then I don't think that is > > > your problem. > > > > Here is what I see: > > > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > > other thread gets signal and calls sem_post. It yields the scheduler. > > This is fine as long as this thread doesn't get a signal > until after sem_post(). Being signal safe doesn't mean > that other threads can't be scheduled. > > > master thread gets semaphore and continues on it's way. > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > It can't keep going if there is a possibility that it can > send the same thread another SIGUSR2. I don't follow. Sorry. > > Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. > > other thread gets signal and calls sem_post. It yields the scheduler. > > Why is it getting SIGUSR1? It is waiting for SIGUSR2, not > SIGUSR1. You need to mask SIGUSR1 before the sem_post() and > until after the sigsuspend() on SIGUSR2. The problem is that it never gets to the sigsuspend. It yields right after the sem_post and gets interrupted again by another SIGUSR1. I see this because it never prints a message that is following the sigsuspend and the sig hander count is incrementing showing me that it is called 2 times before getting to the sigsuspend. > > master thread gets semaphore and continues on it's way. > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > Finally, master scheduler is done and yields the scheduler. > > other thread gets to run now and then it goes into sigsuspend waiting > > for SIGUSR2, but it never gets it because it wasn't masked until > > sigsuspend is called. > > threads are all hung. > > > > The problem is that sem_post should not cause a reschedule of threads > > when inside a signal handler and it does. > > Nope, that is allowable. Please don't confuse signal safe with > "will not yield the CPU". Also, on SMP, there are not guarantees > regardless! OK. Then I suppose what is happening is that it is losing the SIGUSR2. But I don't really know why a signal handler would not be pushed to be high priority. Doesn't it seem logical that it should keep the scheduler past a sem_post? Perhaps that is the issue? Should a thread inside a signal handler have highest priority? > I'm not saying that there isn't a bug somewhere, but don't go > reading more into what the requirements of sem_post() are. I guess I read more into the comment than I should: /* * sem_post() is required to be safe to call from within * signal handlers. Thus, we must enter a critical region. */ I took this to mean (plus the critical enter/leave surrounding it) that sem_post should not yield the scheduler when inside a signal handler. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:15:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B49C216A4CE for ; Fri, 11 Jun 2004 05:15:22 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C7543D55 for ; Fri, 11 Jun 2004 05:15:20 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA90G6; Fri, 11 Jun 2004 13:15:18 +0800 Message-ID: <40C94086.7040505@freebsd.org> Date: Fri, 11 Jun 2004 13:17:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:15:22 -0000 Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > >>On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: >> >>>The critical section should prevent the signal handler >>>from being invoked. Put some printf()'s in after the >>>sem_post() and in the signal handler(). The signal >>>handler printf()'s should always occur after the sem_post(). >>>Plus, you shouldn't be getting that signal since it >>>should be masked until sigsuspend() is called. >>> >>>Is it getting past sem_post() and into sigsuspend() or not? >>>If it is getting past sem_post(), then I don't think that is >>>your problem. >> >>Here is what I see: >> >>master thread calls pthread_kill with SIGUSR1 and waits on semaphore. >>other thread gets signal and calls sem_post. It yields the scheduler. > > > This is fine as long as this thread doesn't get a signal > until after sem_post(). Being signal safe doesn't mean > that other threads can't be scheduled. > You are right here, I don't think any user visible pthread API should block scheduler to schedule other threads. However, I ever said that sem_wait may need to block out signal when it is holding internal semaphore mutex, because sem_post can be used in signal handler (POSIX explicitly wants this), if the current thread hold the mutex, and a signal arrrives, in signal handler, it calls sem_post(), sem_post try to hold the mutex again, it would be failure, then semaphore may be in inconsistent state. This is a corner case caused by sem_post can be used signal handler. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:21:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82A3C16A4CE; Fri, 11 Jun 2004 05:21:22 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 654BD43D46; Fri, 11 Jun 2004 05:21:22 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 0ABDCFD087; Thu, 10 Jun 2004 22:21:18 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38633-03; Thu, 10 Jun 2004 22:21:17 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 35782FD075; Thu, 10 Jun 2004 22:21:17 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40C93D60.3040003@freebsd.org> References: <1086924733.65671.81.camel@server.mcneil.com> <40C93D60.3040003@freebsd.org> Content-Type: text/plain Message-Id: <1086931276.38487.35.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 22:21:17 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:21:22 -0000 On Thu, 2004-06-10 at 22:04, David Xu wrote: > Can you provide some code to demostrate the problem ? I have interest. > > David Xu Yes, here is some code snippets from boehm-gc: master thread doing: int GC_suspend_all() { int n_live_threads = 0; int i; GC_thread p; int result; pthread_t my_thread = pthread_self(); GC_stopping_thread = my_thread; /* debugging only. */ GC_stopping_pid = getpid(); /* debugging only. */ for (i = 0; i < THREAD_TABLE_SZ; i++) { for (p = GC_threads[i]; p != 0; p = p -> next) { if (p -> id != my_thread) { if (p -> flags & FINISHED) continue; if (p -> stop_info.last_stop_count == GC_stop_count) continue; if (p -> thread_blocked) /* Will wait */ continue; n_live_threads++; #if DEBUG_THREADS GC_printf1("Sending suspend signal to 0x%lx\n", p -> id); #endif result = pthread_kill(p -> id, SIG_SUSPEND); switch(result) { case ESRCH: /* Not really there anymore. Possible? */ n_live_threads--; break; case 0: break; default: ABORT("pthread_kill failed"); } } } } return n_live_threads; } and slave threads doing: void GC_suspend_handler(int sig) { int dummy; pthread_t my_thread = pthread_self(); GC_thread me; sigset_t mask; # ifdef PARALLEL_MARK word my_mark_no = GC_mark_no; /* Marker can't proceed until we acknowledge. Thus this is */ /* guaranteed to be the mark_no correspending to our */ /* suspension, i.e. the marker can't have incremented it yet. */ # endif word my_stop_count = GC_stop_count; if (sig != SIG_SUSPEND) ABORT("Bad signal in suspend_handler"); #if DEBUG_THREADS GC_printf1("Suspending 0x%lx\n", my_thread); #endif me = GC_lookup_thread(my_thread); /* The lookup here is safe, since I'm doing this on behalf */ /* of a thread which holds the allocation lock in order */ /* to stop the world. Thus concurrent modification of the */ /* data structure is impossible. */ if (me -> stop_info.last_stop_count == my_stop_count) { /* Duplicate signal. OK if we are retrying. */ if (!GC_retry_signals) { WARN("Duplicate suspend signal in thread %lx\n", pthread_self()); } return; } # ifdef SPARC me -> stop_info.stack_ptr = (ptr_t)GC_save_regs_in_stack(); # else me -> stop_info.stack_ptr = (ptr_t)(&dummy); # endif # ifdef IA64 me -> backing_store_ptr = (ptr_t)GC_save_regs_in_stack(); # endif /* Tell the thread that wants to stop the world that this */ /* thread has been stopped. Note that sem_post() is */ /* the only async-signal-safe primitive in LinuxThreads. */ sem_post(&GC_suspend_ack_sem); me -> stop_info.last_stop_count = my_stop_count; #if DEBUG_THREADS GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); #endif /* Wait until that thread tells us to restart by sending */ /* this thread a SIG_THR_RESTART signal. */ /* SIG_THR_RESTART should be masked at this point. Thus there */ /* is no race. */ if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); # ifdef NO_SIGNALS if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); # endif do { me->stop_info.signal = 0; sigsuspend(&mask); /* Wait for signal */ } while (me->stop_info.signal != SIG_THR_RESTART); /* If the RESTART signal gets lost, we can still lose. That should be */ /* less likely than losing the SUSPEND signal, since we don't do much */ /* between the sem_post and sigsuspend. */ /* We'd need more handshaking to work around that, since we don't want */ /* to accidentally leave a RESTART signal pending, thus causing us to */ /* continue prematurely in a future round. */ #if DEBUG_THREADS GC_printf1("Continuing 0x%lx\n", my_thread); #endif } and here is the output with debug messages: Stopping the world from 0x50d000 Sending suspend signal to 0x9d1400 Suspending 0x9d1400 World stopped from 0x50d000 Pushing stacks from thread 0x50d000 Stack for thread 0x9d1400 = [7fffffeed95c,7fffffeee000) Stack for thread 0x50d000 = [7fffffffcf00,800000000000) World starting Sending restart signal to 0x9d1400 World started Buildfile: build.xml Stopping the world from 0x50d000 Sending suspend signal to 0x9d1400 Waiting for restart #2 of 0x9d1400 There are other things causing output, but you can see that the slave isn't getting to the sigsuspend before it is evoked again from the master thread. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:29:57 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D4E16A4D4 for ; Fri, 11 Jun 2004 05:29:56 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8541B43D39 for ; Fri, 11 Jun 2004 05:29:56 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B5Tn6x013791; Fri, 11 Jun 2004 01:29:49 -0400 (EDT) Date: Fri, 11 Jun 2004 01:29:49 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086930486.38487.28.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:29:57 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote: > > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > > > Here is what I see: > > > > > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > > > other thread gets signal and calls sem_post. It yields the scheduler. > > > > This is fine as long as this thread doesn't get a signal > > until after sem_post(). Being signal safe doesn't mean > > that other threads can't be scheduled. > > > > > master thread gets semaphore and continues on it's way. > > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > > > It can't keep going if there is a possibility that it can > > send the same thread another SIGUSR2. > > I don't follow. Sorry. If the master thread does: for (i = 0; i < 4; i++) { pthread_kill(slave, SIGUSR1); sem_wait(&slave_semaphore); pthread_kill(slave, SIGUSR2); } You can see that there is a potential race condition where the slave thread gets SIGUSR1 and SIGUSR2 very close together. It is even possible to get them together in one sigsuspend() (if they are both unmasked in the suspend mask). You could fix the race by blocking SIGUSR1 from within the signal handler (like I described in my last email). > > > Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. > > > other thread gets signal and calls sem_post. It yields the scheduler. > > > > Why is it getting SIGUSR1? It is waiting for SIGUSR2, not > > SIGUSR1. You need to mask SIGUSR1 before the sem_post() and > > until after the sigsuspend() on SIGUSR2. > > The problem is that it never gets to the sigsuspend. It yields right > after the sem_post and gets interrupted again by another SIGUSR1. I see Right, you need to block SIGUSR1 _before_ sem_post() and unblock it after sigsuspend(). > this because it never prints a message that is following the sigsuspend > and the sig hander count is incrementing showing me that it is called 2 > times before getting to the sigsuspend. [ ... ] > > Nope, that is allowable. Please don't confuse signal safe with > > "will not yield the CPU". Also, on SMP, there are not guarantees > > regardless! > > OK. Then I suppose what is happening is that it is losing the SIGUSR2. > But I don't really know why a signal handler would not be pushed to be > high priority. Doesn't it seem logical that it should keep the > scheduler past a sem_post? Perhaps that is the issue? Should a thread > inside a signal handler have highest priority? It doesn't solve anything because it could still block on other lower-level locks, and the posted thread could be run on another CPU. > > I'm not saying that there isn't a bug somewhere, but don't go > > reading more into what the requirements of sem_post() are. > > I guess I read more into the comment than I should: > > /* > * sem_post() is required to be safe to call from within > * signal handlers. Thus, we must enter a critical region. > */ > > I took this to mean (plus the critical enter/leave surrounding it) that > sem_post should not yield the scheduler when inside a signal handler. It tries hard not to leave the scheduler, but mostly it prevents signals from getting delivered. If the thread blocks on a low-level lock (that used to protect a semaphore), then it can block. It could be that semaphores aren't working correctly, but the fact that you can yield the CPU isn't the real problem. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:53:17 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE4D116A4CE for ; Fri, 11 Jun 2004 05:53:17 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF5C43D4C for ; Fri, 11 Jun 2004 05:53:15 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 12ADDFD059; Thu, 10 Jun 2004 22:53:15 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38653-04; Thu, 10 Jun 2004 22:53:14 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 92EECFD01A; Thu, 10 Jun 2004 22:53:14 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086933194.38839.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 22:53:14 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 05:53:17 -0000 On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote: > > > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > > > > > Here is what I see: > > > > > > > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > > > > other thread gets signal and calls sem_post. It yields the scheduler. > > > > > > This is fine as long as this thread doesn't get a signal > > > until after sem_post(). Being signal safe doesn't mean > > > that other threads can't be scheduled. > > > > > > > master thread gets semaphore and continues on it's way. > > > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > > > > > It can't keep going if there is a possibility that it can > > > send the same thread another SIGUSR2. > > > > I don't follow. Sorry. > > If the master thread does: > > for (i = 0; i < 4; i++) { > pthread_kill(slave, SIGUSR1); > sem_wait(&slave_semaphore); > pthread_kill(slave, SIGUSR2); > } > > You can see that there is a potential race condition where > the slave thread gets SIGUSR1 and SIGUSR2 very close together. > It is even possible to get them together in one sigsuspend() > (if they are both unmasked in the suspend mask). > > You could fix the race by blocking SIGUSR1 from within > the signal handler (like I described in my last email). I take it then that when a signal handler is invoked that it's signal isn't masked while running. It isn't like a standard hardware interrupt then. I'm trying as you suggest and will post results. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:00:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1587C16A4CE for ; Fri, 11 Jun 2004 06:00:44 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A7A043D53 for ; Fri, 11 Jun 2004 06:00:42 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA90LZ; Fri, 11 Jun 2004 14:00:30 +0800 Message-ID: <40C94B1E.8030202@freebsd.org> Date: Fri, 11 Jun 2004 14:03:10 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086931276.38487.35.camel@server.mcneil.com> In-Reply-To: <1086931276.38487.35.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:00:44 -0000 I think there is a race in GC_suspend_handler, code between sem_post and sigsuspend has race, let me demostrate: Master : pthread_kill(slave1, SIGUSR1); Master : semwait Slave1 : sempost Master : semwait return Master : pthread_kill(slave, SIGUSR2); Master : pthread_kill(slave2, SIGUSR1); ... Slave1 : scheduler switched to slave1, found there is SIGUSR2 in pending set Slave1 : invoke SIGUSR2 handler withinsa_handler Slave1 : SIGUSR2 handler return Slave1 : sigsuspend SIGUSR2 because SIGUSR2 was already handled, it hangs in sigsuspend, and never return. It seems the code has the race bug. I think you should use sigaction and set additional mask for SIGUSR1. code looks like this: struct sigaction sa; sigemptyset(&sa.sa_mask); sigaddset(&sa.sa_mask, SIGUSR2); sa.sa_handler = GC_suspend_handler; sigaction(SIGUSR1, &sa, NULL); this code will block out SIGUSR2 in GC_suspend_handler, and when you call sigsuspend for SIGUSR2, it should return if there is SIGUSR2 pending or it SIGUSR2 comes later. David Xu Sean McNeil wrote: > On Thu, 2004-06-10 at 22:04, David Xu wrote: > >>Can you provide some code to demostrate the problem ? I have interest. >> >>David Xu > > > Yes, here is some code snippets from boehm-gc: > > master thread doing: > > int GC_suspend_all() > { > int n_live_threads = 0; > int i; > GC_thread p; > int result; > pthread_t my_thread = pthread_self(); > > GC_stopping_thread = my_thread; /* debugging only. */ > GC_stopping_pid = getpid(); /* debugging only. > */ > for (i = 0; i < THREAD_TABLE_SZ; i++) { > for (p = GC_threads[i]; p != 0; p = p -> next) { > if (p -> id != my_thread) { > if (p -> flags & FINISHED) continue; > if (p -> stop_info.last_stop_count == GC_stop_count) > continue; > if (p -> thread_blocked) /* Will wait */ continue; > n_live_threads++; > #if DEBUG_THREADS > GC_printf1("Sending suspend signal to 0x%lx\n", p -> id); > #endif > > result = pthread_kill(p -> id, SIG_SUSPEND); > switch(result) { > case ESRCH: > /* Not really there anymore. Possible? */ > n_live_threads--; > break; > case 0: > break; > default: > ABORT("pthread_kill failed"); > } > } > } > } > return n_live_threads; > } > > and slave threads doing: > > void GC_suspend_handler(int sig) > { > int dummy; > pthread_t my_thread = pthread_self(); > GC_thread me; > sigset_t mask; > # ifdef PARALLEL_MARK > word my_mark_no = GC_mark_no; > /* Marker can't proceed until we acknowledge. Thus this is > */ > /* guaranteed to be the mark_no correspending to our > */ > /* suspension, i.e. the marker can't have incremented it yet. > */ > # endif > word my_stop_count = GC_stop_count; > > if (sig != SIG_SUSPEND) ABORT("Bad signal in suspend_handler"); > > #if DEBUG_THREADS > GC_printf1("Suspending 0x%lx\n", my_thread); > #endif > > me = GC_lookup_thread(my_thread); > /* The lookup here is safe, since I'm doing this on behalf */ > /* of a thread which holds the allocation lock in order */ > /* to stop the world. Thus concurrent modification of the */ > /* data structure is impossible. */ > if (me -> stop_info.last_stop_count == my_stop_count) { > /* Duplicate signal. OK if we are retrying. */ > if (!GC_retry_signals) { > WARN("Duplicate suspend signal in thread %lx\n", > pthread_self()); > } > return; > } > # ifdef SPARC > me -> stop_info.stack_ptr = (ptr_t)GC_save_regs_in_stack(); > # else > me -> stop_info.stack_ptr = (ptr_t)(&dummy); > # endif > # ifdef IA64 > me -> backing_store_ptr = (ptr_t)GC_save_regs_in_stack(); > # endif > > /* Tell the thread that wants to stop the world that this */ > /* thread has been stopped. Note that sem_post() is */ > /* the only async-signal-safe primitive in LinuxThreads. */ > sem_post(&GC_suspend_ack_sem); > me -> stop_info.last_stop_count = my_stop_count; > > #if DEBUG_THREADS > GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, > my_thread); > #endif > > /* Wait until that thread tells us to restart by sending */ > /* this thread a SIG_THR_RESTART signal. */ > /* SIG_THR_RESTART should be masked at this point. Thus there > */ > /* is no race. */ > if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); > if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() > failed"); > # ifdef NO_SIGNALS > if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); > # endif > do { > me->stop_info.signal = 0; > sigsuspend(&mask); /* Wait for signal */ > } while (me->stop_info.signal != SIG_THR_RESTART); > /* If the RESTART signal gets lost, we can still lose. That should > be */ > /* less likely than losing the SUSPEND signal, since we don't do > much */ > /* between the sem_post and sigsuspend. > */ > /* We'd need more handshaking to work around that, since we don't > want */ > /* to accidentally leave a RESTART signal pending, thus causing us > to */ > /* continue prematurely in a future round. > */ > > #if DEBUG_THREADS > GC_printf1("Continuing 0x%lx\n", my_thread); > #endif > } > > and here is the output with debug messages: > > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > Suspending 0x9d1400 > World stopped from 0x50d000 > Pushing stacks from thread 0x50d000 > Stack for thread 0x9d1400 = [7fffffeed95c,7fffffeee000) > Stack for thread 0x50d000 = [7fffffffcf00,800000000000) > World starting > Sending restart signal to 0x9d1400 > World started > Buildfile: build.xml > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > Waiting for restart #2 of 0x9d1400 > > There are other things causing output, but you can see that the slave > isn't getting to the sigsuspend before it is evoked again from the > master thread. > > > From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:02:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD0B516A4CE; Fri, 11 Jun 2004 06:02:15 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7C743D1F; Fri, 11 Jun 2004 06:02:15 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B6296x019860; Fri, 11 Jun 2004 02:02:09 -0400 (EDT) Date: Fri, 11 Jun 2004 02:02:09 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086931276.38487.35.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:02:15 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 22:04, David Xu wrote: > > Can you provide some code to demostrate the problem ? I have interest. > > > > David Xu > > Yes, here is some code snippets from boehm-gc: > > master thread doing: > > int GC_suspend_all() > { > int n_live_threads = 0; > int i; > GC_thread p; > int result; > pthread_t my_thread = pthread_self(); > > GC_stopping_thread = my_thread; /* debugging only. */ > GC_stopping_pid = getpid(); /* debugging only. */ > for (i = 0; i < THREAD_TABLE_SZ; i++) { > for (p = GC_threads[i]; p != 0; p = p -> next) { > if (p -> id != my_thread) { > if (p -> flags & FINISHED) continue; > if (p -> stop_info.last_stop_count == GC_stop_count) continue; > if (p -> thread_blocked) /* Will wait */ continue; > n_live_threads++; > #if DEBUG_THREADS > GC_printf1("Sending suspend signal to 0x%lx\n", p -> id); > #endif > > result = pthread_kill(p -> id, SIG_SUSPEND); > switch(result) { > case ESRCH: > /* Not really there anymore. Possible? */ > n_live_threads--; > break; > case 0: > break; > default: > ABORT("pthread_kill failed"); > } > } > } > } > return n_live_threads; > } Am I blind, or is there no sem_wait() above after pthread_kill(). > and slave threads doing: > > void GC_suspend_handler(int sig) > { > int dummy; > pthread_t my_thread = pthread_self(); > GC_thread me; > sigset_t mask; > # ifdef PARALLEL_MARK > word my_mark_no = GC_mark_no; > /* Marker can't proceed until we acknowledge. Thus this is */ > /* guaranteed to be the mark_no correspending to our */ > /* suspension, i.e. the marker can't have incremented it yet. */ > # endif > word my_stop_count = GC_stop_count; > > if (sig != SIG_SUSPEND) ABORT("Bad signal in suspend_handler"); > > #if DEBUG_THREADS > GC_printf1("Suspending 0x%lx\n", my_thread); > #endif > > me = GC_lookup_thread(my_thread); > /* The lookup here is safe, since I'm doing this on behalf */ > /* of a thread which holds the allocation lock in order */ > /* to stop the world. Thus concurrent modification of the */ > /* data structure is impossible. */ > if (me -> stop_info.last_stop_count == my_stop_count) { > /* Duplicate signal. OK if we are retrying. */ > if (!GC_retry_signals) { > WARN("Duplicate suspend signal in thread %lx\n", > pthread_self()); > } > return; > } > # ifdef SPARC > me -> stop_info.stack_ptr = (ptr_t)GC_save_regs_in_stack(); > # else > me -> stop_info.stack_ptr = (ptr_t)(&dummy); > # endif > # ifdef IA64 > me -> backing_store_ptr = (ptr_t)GC_save_regs_in_stack(); > # endif > > /* Tell the thread that wants to stop the world that this */ > /* thread has been stopped. Note that sem_post() is */ > /* the only async-signal-safe primitive in LinuxThreads. */ > sem_post(&GC_suspend_ack_sem); > me -> stop_info.last_stop_count = my_stop_count; > > #if DEBUG_THREADS > GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); > #endif > > /* Wait until that thread tells us to restart by sending */ > /* this thread a SIG_THR_RESTART signal. */ > /* SIG_THR_RESTART should be masked at this point. Thus there */ > /* is no race. */ You also need to make sure SIGUSR1 is masked while in this function. It could possibly get another one after the sem_post() and before the sigsuspend() below. > if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); > if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); > # ifdef NO_SIGNALS > if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); > # endif > do { > me->stop_info.signal = 0; > sigsuspend(&mask); /* Wait for signal */ > } while (me->stop_info.signal != SIG_THR_RESTART); > /* If the RESTART signal gets lost, we can still lose. That should be */ > /* less likely than losing the SUSPEND signal, since we don't do much */ > /* between the sem_post and sigsuspend. */ > /* We'd need more handshaking to work around that, since we don't want */ > /* to accidentally leave a RESTART signal pending, thus causing us to */ > /* continue prematurely in a future round. */ > > #if DEBUG_THREADS > GC_printf1("Continuing 0x%lx\n", my_thread); > #endif > } > > and here is the output with debug messages: > > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > Suspending 0x9d1400 > World stopped from 0x50d000 > Pushing stacks from thread 0x50d000 > Stack for thread 0x9d1400 = [7fffffeed95c,7fffffeee000) > Stack for thread 0x50d000 = [7fffffffcf00,800000000000) > World starting > Sending restart signal to 0x9d1400 > World started > Buildfile: build.xml > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > Waiting for restart #2 of 0x9d1400 > > There are other things causing output, but you can see that the slave > isn't getting to the sigsuspend before it is evoked again from the > master thread. Something is weird. It's not getting the first restart, but yet it's past the sem_post() in the second restart. Try displaying the return from sem_post(). And where's the missing sem_wait()? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:06:09 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52B1216A4CE for ; Fri, 11 Jun 2004 06:06:09 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0089A43D2D for ; Fri, 11 Jun 2004 06:06:09 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B6686x020568; Fri, 11 Jun 2004 02:06:08 -0400 (EDT) Date: Fri, 11 Jun 2004 02:06:08 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086933194.38839.3.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:06:09 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote: > > > > > > > > It can't keep going if there is a possibility that it can > > > > send the same thread another SIGUSR2. > > > > > > I don't follow. Sorry. > > > > If the master thread does: > > > > for (i = 0; i < 4; i++) { > > pthread_kill(slave, SIGUSR1); > > sem_wait(&slave_semaphore); > > pthread_kill(slave, SIGUSR2); > > } > > > > You can see that there is a potential race condition where > > the slave thread gets SIGUSR1 and SIGUSR2 very close together. > > It is even possible to get them together in one sigsuspend() > > (if they are both unmasked in the suspend mask). > > > > You could fix the race by blocking SIGUSR1 from within > > the signal handler (like I described in my last email). > > I take it then that when a signal handler is invoked that it's signal > isn't masked while running. It isn't like a standard hardware interrupt > then. I'm trying as you suggest and will post results. Like I said before, it depends on the mask of the installed signal handler (sigact.sa_mask). You should use sigaction() and not signal() to get the desired behavior. You're other output looked strange. I was expecting the "restart" count to start at 1, not 2. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:10:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC4B416A4CE; Fri, 11 Jun 2004 06:10:15 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6150C43D41; Fri, 11 Jun 2004 06:10:15 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 3BF8DFD059; Thu, 10 Jun 2004 23:09:52 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38633-06; Thu, 10 Jun 2004 23:09:51 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 7A8CAFD01A; Thu, 10 Jun 2004 23:09:51 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086934191.85039.1.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 23:09:51 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:10:15 -0000 On Thu, 2004-06-10 at 23:02, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 22:04, David Xu wrote: > > > Can you provide some code to demostrate the problem ? I have interest. > > > > > > David Xu > > > > Yes, here is some code snippets from boehm-gc: > > > > master thread doing: > > > > int GC_suspend_all() > > { > > int n_live_threads = 0; > > int i; > > GC_thread p; > > int result; > > pthread_t my_thread = pthread_self(); > > > > GC_stopping_thread = my_thread; /* debugging only. */ > > GC_stopping_pid = getpid(); /* debugging only. */ > > for (i = 0; i < THREAD_TABLE_SZ; i++) { > > for (p = GC_threads[i]; p != 0; p = p -> next) { > > if (p -> id != my_thread) { > > if (p -> flags & FINISHED) continue; > > if (p -> stop_info.last_stop_count == GC_stop_count) continue; > > if (p -> thread_blocked) /* Will wait */ continue; > > n_live_threads++; > > #if DEBUG_THREADS > > GC_printf1("Sending suspend signal to 0x%lx\n", p -> id); > > #endif > > > > result = pthread_kill(p -> id, SIG_SUSPEND); > > switch(result) { > > case ESRCH: > > /* Not really there anymore. Possible? */ > > n_live_threads--; > > break; > > case 0: > > break; > > default: > > ABORT("pthread_kill failed"); > > } > > } > > } > > } > > return n_live_threads; > > } > > Am I blind, or is there no sem_wait() above after pthread_kill(). No, you aren't blind. It is done by the calling routine of above: n_live_threads = GC_suspend_all(); if (GC_retry_signals) { unsigned long wait_usecs = 0; /* Total wait since retry. */ # define WAIT_UNIT 3000 # define RETRY_INTERVAL 100000 for (;;) { int ack_count; sem_getvalue(&GC_suspend_ack_sem, &ack_count); if (ack_count == n_live_threads) break; if (wait_usecs > RETRY_INTERVAL) { int newly_sent = GC_suspend_all(); # ifdef CONDPRINT if (GC_print_stats) { GC_printf1("Resent %ld signals after timeout\n", newly_sent); } # endif sem_getvalue(&GC_suspend_ack_sem, &ack_count); if (newly_sent < n_live_threads - ack_count) { WARN("Lost some threads during GC_stop_world?!\n",0); n_live_threads = ack_count + newly_sent; } wait_usecs = 0; } usleep(WAIT_UNIT); wait_usecs += WAIT_UNIT; } } for (i = 0; i < n_live_threads; i++) { if (0 != (code = sem_wait(&GC_suspend_ack_sem))) { GC_err_printf1("Sem_wait returned %ld\n", (unsigned long)code); ABORT("sem_wait for handler failed"); } } > > and slave threads doing: > > > > void GC_suspend_handler(int sig) > > { > > int dummy; > > pthread_t my_thread = pthread_self(); > > GC_thread me; > > sigset_t mask; > > # ifdef PARALLEL_MARK > > word my_mark_no = GC_mark_no; > > /* Marker can't proceed until we acknowledge. Thus this is */ > > /* guaranteed to be the mark_no correspending to our */ > > /* suspension, i.e. the marker can't have incremented it yet. */ > > # endif > > word my_stop_count = GC_stop_count; > > > > if (sig != SIG_SUSPEND) ABORT("Bad signal in suspend_handler"); > > > > #if DEBUG_THREADS > > GC_printf1("Suspending 0x%lx\n", my_thread); > > #endif > > > > me = GC_lookup_thread(my_thread); > > /* The lookup here is safe, since I'm doing this on behalf */ > > /* of a thread which holds the allocation lock in order */ > > /* to stop the world. Thus concurrent modification of the */ > > /* data structure is impossible. */ > > if (me -> stop_info.last_stop_count == my_stop_count) { > > /* Duplicate signal. OK if we are retrying. */ > > if (!GC_retry_signals) { > > WARN("Duplicate suspend signal in thread %lx\n", > > pthread_self()); > > } > > return; > > } > > # ifdef SPARC > > me -> stop_info.stack_ptr = (ptr_t)GC_save_regs_in_stack(); > > # else > > me -> stop_info.stack_ptr = (ptr_t)(&dummy); > > # endif > > # ifdef IA64 > > me -> backing_store_ptr = (ptr_t)GC_save_regs_in_stack(); > > # endif > > > > /* Tell the thread that wants to stop the world that this */ > > /* thread has been stopped. Note that sem_post() is */ > > /* the only async-signal-safe primitive in LinuxThreads. */ > > sem_post(&GC_suspend_ack_sem); > > me -> stop_info.last_stop_count = my_stop_count; > > > > #if DEBUG_THREADS > > GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); > > #endif > > > > /* Wait until that thread tells us to restart by sending */ > > /* this thread a SIG_THR_RESTART signal. */ > > /* SIG_THR_RESTART should be masked at this point. Thus there */ > > /* is no race. */ > > You also need to make sure SIGUSR1 is masked while in this > function. It could possibly get another one after the sem_post() > and before the sigsuspend() below. > > > if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); > > if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); > > # ifdef NO_SIGNALS > > if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); > > if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); > > if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); > > if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); > > # endif > > do { > > me->stop_info.signal = 0; > > sigsuspend(&mask); /* Wait for signal */ > > } while (me->stop_info.signal != SIG_THR_RESTART); > > /* If the RESTART signal gets lost, we can still lose. That should be */ > > /* less likely than losing the SUSPEND signal, since we don't do much */ > > /* between the sem_post and sigsuspend. */ > > /* We'd need more handshaking to work around that, since we don't want */ > > /* to accidentally leave a RESTART signal pending, thus causing us to */ > > /* continue prematurely in a future round. */ > > > > #if DEBUG_THREADS > > GC_printf1("Continuing 0x%lx\n", my_thread); > > #endif > > } > > > > and here is the output with debug messages: > > > > Stopping the world from 0x50d000 > > Sending suspend signal to 0x9d1400 > > Suspending 0x9d1400 > > World stopped from 0x50d000 > > Pushing stacks from thread 0x50d000 > > Stack for thread 0x9d1400 = [7fffffeed95c,7fffffeee000) > > Stack for thread 0x50d000 = [7fffffffcf00,800000000000) > > World starting > > Sending restart signal to 0x9d1400 > > World started > > Buildfile: build.xml > > Stopping the world from 0x50d000 > > Sending suspend signal to 0x9d1400 > > Waiting for restart #2 of 0x9d1400 > > > > There are other things causing output, but you can see that the slave > > isn't getting to the sigsuspend before it is evoked again from the > > master thread. > > Something is weird. It's not getting the first restart, but > yet it's past the sem_post() in the second restart. Try displaying > the return from sem_post(). And where's the missing sem_wait()? From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:26:06 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64D9516A4CE for ; Fri, 11 Jun 2004 06:26:06 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B08143D53 for ; Fri, 11 Jun 2004 06:26:06 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 06890FD059; Thu, 10 Jun 2004 23:26:06 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38653-07; Thu, 10 Jun 2004 23:26:05 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 1FF88FD01A; Thu, 10 Jun 2004 23:26:05 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086935164.85387.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 23:26:04 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:26:06 -0000 On Thu, 2004-06-10 at 23:06, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote: > > > > > > > > > > It can't keep going if there is a possibility that it can > > > > > send the same thread another SIGUSR2. > > > > > > > > I don't follow. Sorry. > > > > > > If the master thread does: > > > > > > for (i = 0; i < 4; i++) { > > > pthread_kill(slave, SIGUSR1); > > > sem_wait(&slave_semaphore); > > > pthread_kill(slave, SIGUSR2); > > > } > > > > > > You can see that there is a potential race condition where > > > the slave thread gets SIGUSR1 and SIGUSR2 very close together. > > > It is even possible to get them together in one sigsuspend() > > > (if they are both unmasked in the suspend mask). > > > > > > You could fix the race by blocking SIGUSR1 from within > > > the signal handler (like I described in my last email). > > > > I take it then that when a signal handler is invoked that it's signal > > isn't masked while running. It isn't like a standard hardware interrupt > > then. I'm trying as you suggest and will post results. > > Like I said before, it depends on the mask of the installed > signal handler (sigact.sa_mask). You should use sigaction() > and not signal() to get the desired behavior. > > You're other output looked strange. I was expecting the > "restart" count to start at 1, not 2. That is my fault. I didn't give enough output. That count is how many times world is stopped. Here is all the output: Stopping the world from 0x50d000 World stopped from 0x50d000 Pushing stacks from thread 0x50d000 Stack for thread 0x50d000 = [7fffffffdfa0,800000000000) World starting World started About to start new thread from thread 0x50D000 Started thread 0x9D1400 Starting thread 0x9d1400 pid = 85636 sp = 0x7fffffeedf80 start_routine = 0x200db4960 Unable to locate tools.jar. Expected to find it in /usr/local/gcc-cvs/lib/tools.jar Stopping the world from 0x50d000 Sending suspend signal to 0x9d1400 Suspending 0x9d1400 World stopped from 0x50d000 Pushing stacks from thread 0x50d000 Stack for thread 0x9d1400 = [7fffffeed94c,7fffffeee000) Stack for thread 0x50d000 = [7fffffffcf00,800000000000) World starting Sending restart signal to 0x9d1400 World started In GC_restart_handler for 0x9d1400 Waiting for restart #2 of 0x9d1400 Buildfile: build.xml Stopping the world from 0x50d000 Sending suspend signal to 0x9d1400 This is with the following change to the code, by the way, that masks everything but the (SIG_THR_RESTART) SIGUSR2 before calling sem_post. So that didn't solve my problem: /* Wait until that thread tells us to restart by sending */ /* this thread a SIG_THR_RESTART signal. */ /* SIG_THR_RESTART should be masked at this point. Thus there */ /* is no race. */ if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); # ifdef NO_SIGNALS if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); # endif pthread_sigmask(SIG_SETMASK, &mask, NULL); /* Tell the thread that wants to stop the world that this */ /* thread has been stopped. Note that sem_post() is */ /* the only async-signal-safe primitive in LinuxThreads. */ sem_post(&GC_suspend_ack_sem); me -> stop_info.last_stop_count = my_stop_count; #if DEBUG_THREADS GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); #endif do { me->stop_info.signal = 0; sigsuspend(&mask); /* Wait for signal */ } while (me->stop_info.signal != SIG_THR_RESTART); Looks like I also missed some additional related code. There is a signal handler installed for SIGUSR2: void GC_restart_handler(int sig) { pthread_t my_thread = pthread_self(); GC_thread me; if (sig != SIG_THR_RESTART) ABORT("Bad signal in suspend_handler"); /* Let the GC_suspend_handler() know that we got a SIG_THR_RESTART. */ /* The lookup here is safe, since I'm doing this on behalf */ /* of a thread which holds the allocation lock in order */ /* to stop the world. Thus concurrent modification of the */ /* data structure is impossible. */ me = GC_lookup_thread(my_thread); me->stop_info.signal = SIG_THR_RESTART; /* ** Note: even if we didn't do anything useful here, ** it would still be necessary to have a signal handler, ** rather than ignoring the signals, otherwise ** the signals will not be delivered at all, and ** will thus not interrupt the sigsuspend() above. */ #if DEBUG_THREADS GC_printf1("In GC_restart_handler for 0x%lx\n", pthread_self()); #endif } From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:29:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7436216A4CE; Fri, 11 Jun 2004 06:29:22 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6526943D41; Fri, 11 Jun 2004 06:29:22 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 44A83FD059; Thu, 10 Jun 2004 23:29:20 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38633-08; Thu, 10 Jun 2004 23:29:19 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id BF4BAFD01A; Thu, 10 Jun 2004 23:29:19 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40C94B1E.8030202@freebsd.org> References: <1086931276.38487.35.camel@server.mcneil.com> <40C94B1E.8030202@freebsd.org> Content-Type: text/plain Message-Id: <1086935359.85387.14.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 23:29:19 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:29:22 -0000 On Thu, 2004-06-10 at 23:03, David Xu wrote: > I think there is a race in GC_suspend_handler, > code between sem_post and sigsuspend has race, let me demostrate: > > Master : pthread_kill(slave1, SIGUSR1); > Master : semwait > Slave1 : sempost > Master : semwait return > Master : pthread_kill(slave, SIGUSR2); > Master : pthread_kill(slave2, SIGUSR1); > ... > Slave1 : scheduler switched to slave1, found there > is SIGUSR2 in pending set > Slave1 : invoke SIGUSR2 handler withinsa_handler > Slave1 : SIGUSR2 handler return > Slave1 : sigsuspend SIGUSR2 > because SIGUSR2 was already handled, it hangs > in sigsuspend, and never return. > > It seems the code has the race bug. I think you should > use sigaction and set additional mask for SIGUSR1. > code looks like this: > > struct sigaction sa; > > sigemptyset(&sa.sa_mask); > sigaddset(&sa.sa_mask, SIGUSR2); > sa.sa_handler = GC_suspend_handler; > sigaction(SIGUSR1, &sa, NULL); > > this code will block out SIGUSR2 in GC_suspend_handler, > and when you call sigsuspend for SIGUSR2, it should return > if there is SIGUSR2 pending or it SIGUSR2 comes later. Actually, what I think is happening now is that the sigaction for SIGUSR2 is being called but the sigsuspend isn't being release. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:42:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE1716A4CE for ; Fri, 11 Jun 2004 06:42:13 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD5D43D54 for ; Fri, 11 Jun 2004 06:42:12 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B6fh6x027693; Fri, 11 Jun 2004 02:41:44 -0400 (EDT) Date: Fri, 11 Jun 2004 02:41:43 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086935164.85387.11.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:42:13 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 23:06, Daniel Eischen wrote: > > > > Like I said before, it depends on the mask of the installed > > signal handler (sigact.sa_mask). You should use sigaction() > > and not signal() to get the desired behavior. > > > > You're other output looked strange. I was expecting the > > "restart" count to start at 1, not 2. > > That is my fault. I didn't give enough output. That count is how many > times world is stopped. Here is all the output: > > Stopping the world from 0x50d000 > World stopped from 0x50d000 > Pushing stacks from thread 0x50d000 > Stack for thread 0x50d000 = [7fffffffdfa0,800000000000) > World starting > World started > About to start new thread from thread 0x50D000 > Started thread 0x9D1400 > Starting thread 0x9d1400 > pid = 85636 > sp = 0x7fffffeedf80 > start_routine = 0x200db4960 > Unable to locate tools.jar. Expected to find it in /usr/local/gcc-cvs/lib/tools.jar > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > Suspending 0x9d1400 > World stopped from 0x50d000 > Pushing stacks from thread 0x50d000 > Stack for thread 0x9d1400 = [7fffffeed94c,7fffffeee000) > Stack for thread 0x50d000 = [7fffffffcf00,800000000000) > World starting > Sending restart signal to 0x9d1400 > World started > In GC_restart_handler for 0x9d1400 > Waiting for restart #2 of 0x9d1400 > Buildfile: build.xml > Stopping the world from 0x50d000 > Sending suspend signal to 0x9d1400 > > This is with the following change to the code, by the way, that masks > everything but the (SIG_THR_RESTART) SIGUSR2 before calling sem_post. So > that didn't solve my problem: > > /* Wait until that thread tells us to restart by sending */ > /* this thread a SIG_THR_RESTART signal. */ > /* SIG_THR_RESTART should be masked at this point. Thus there */ > /* is no race. */ > if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); > if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() > failed"); > # ifdef NO_SIGNALS > if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); > # endif > > pthread_sigmask(SIG_SETMASK, &mask, NULL); This isn't correct. You're unmasking SIG_THR_RESTART, not masking it. See the sigfillset() above followed by sigdelset(). Also, by masking it here in the signal handler instead of where the signal handler is installed, you have to unmask it after sigsuspend() returns. And actually, you have to return the signal mask to the state from before the signal handler was invoked. The best and easiest way is to just mask SIG_THR_RESTART in act.sa_mask from wherever the handler is installed. The other way is to install the signal handler with SA_SIGINFO and grab the original mask from ucp->uc_sigmask (which will be the 3rd argument to the signal handler) and use that to restore it. See David's email for how to mask SIG_THR_RESTART when the signal handler is installed. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:43:06 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F85C16A4CE; Fri, 11 Jun 2004 06:43:06 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10CA443D46; Fri, 11 Jun 2004 06:43:06 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B6gm6x027866; Fri, 11 Jun 2004 02:42:49 -0400 (EDT) Date: Fri, 11 Jun 2004 02:42:48 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086935359.85387.14.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:43:06 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 23:03, David Xu wrote: > > I think there is a race in GC_suspend_handler, > > code between sem_post and sigsuspend has race, let me demostrate: > > > > Master : pthread_kill(slave1, SIGUSR1); > > Master : semwait > > Slave1 : sempost > > Master : semwait return > > Master : pthread_kill(slave, SIGUSR2); > > Master : pthread_kill(slave2, SIGUSR1); > > ... > > Slave1 : scheduler switched to slave1, found there > > is SIGUSR2 in pending set > > Slave1 : invoke SIGUSR2 handler withinsa_handler > > Slave1 : SIGUSR2 handler return > > Slave1 : sigsuspend SIGUSR2 > > because SIGUSR2 was already handled, it hangs > > in sigsuspend, and never return. > > > > It seems the code has the race bug. I think you should > > use sigaction and set additional mask for SIGUSR1. > > code looks like this: > > > > struct sigaction sa; > > > > sigemptyset(&sa.sa_mask); > > sigaddset(&sa.sa_mask, SIGUSR2); > > sa.sa_handler = GC_suspend_handler; > > sigaction(SIGUSR1, &sa, NULL); > > > > this code will block out SIGUSR2 in GC_suspend_handler, > > and when you call sigsuspend for SIGUSR2, it should return > > if there is SIGUSR2 pending or it SIGUSR2 comes later. > > Actually, what I think is happening now is that the sigaction for > SIGUSR2 is being called but the sigsuspend isn't being release. Because the handler is being called before sigsuspend() is hit. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 07:16:12 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9640F16A4CE; Fri, 11 Jun 2004 07:16:12 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FFB443D2F; Fri, 11 Jun 2004 07:16:12 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B7G16x003864; Fri, 11 Jun 2004 03:16:01 -0400 (EDT) Date: Fri, 11 Jun 2004 03:16:00 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 07:16:12 -0000 Here is a simple test program. -- Dan Eischen /* * test_sr.c * * Demonstrate use of signals & semaphores for suspending and * resuming threads. */ #include #include #include #include #include #include #include #include #ifndef NUM_THREADS #define NUM_THREADS 5 #endif static sem_t semaphore; static int done = 0; static pthread_t tids[NUM_THREADS]; static void errno_abort(char *msg) { printf("%s, errno %d\n", msg, errno); abort(); } static void err_abort(int status, char *msg) { printf("%s, status %d\n", msg, status); abort(); } static void sighandler(int sig, siginfo_t *info, ucontext_t *ucp) { sigset_t mask; switch (sig) { case SIGUSR1: printf("Thread %p pausing.\n", pthread_self()); sigfillset(&mask); sigdelset(&mask, SIGUSR2); sem_post(&semaphore); sigsuspend(&mask); printf("Thread %p successfully resumed.\n", pthread_self()); break; case SIGUSR2: printf("Thread %p got resume signal.\n", pthread_self()); break; } } /* * Thread start routine to wait on a semaphore. */ static void * worker(void *arg) { int num = (int)arg; int x; num = (int)arg; x = num * 10; printf ("Thread %d starting.\n", num); while (!done) { x = x + 1; x = x - 1; } printf("Thread %d stopping.\n", num); return (NULL); } static void pause_threads(void) { int i; printf("Master: pausing all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR1); if (sem_wait(&semaphore) == -1) errno_abort("Wait on semaphore"); } } static void resume_threads(void) { int i; printf("Master: resuming all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR2); } } int main(int argc, char *argv[]) { struct sigaction act; int status; int i; if (sem_init (&semaphore, 0, 0) == -1) errno_abort ("Init semaphore"); /* Mask all signals while in the signal handler. */ sigfillset(&act.sa_mask); act.sa_handler = sighandler; act.sa_flags = SA_SIGINFO | SA_RESTART; sigaction(SIGUSR1, &act, NULL); sigaction(SIGUSR2, &act, NULL); /* * Create some worker threads. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_create(&tids[i], NULL, worker, (void *)i); if (status != 0) err_abort (status, "Create thread"); } sleep (1); for (i = 0; i < 5; i++) { pause_threads(); resume_threads(); } done = 1; /* * Wait for all threads to complete. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_join(tids[i], NULL); if (status != 0) err_abort(status, "Join thread"); } return (0); } From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 07:45:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA16416A4CE; Fri, 11 Jun 2004 07:45:51 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A7243D1F; Fri, 11 Jun 2004 07:45:49 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 156C8FD087; Fri, 11 Jun 2004 00:45:29 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28084-02; Fri, 11 Jun 2004 00:45:28 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 61062FD075; Fri, 11 Jun 2004 00:45:28 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086939928.10026.26.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 00:45:28 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 07:45:51 -0000 OK, I think I have it figured out.... The problem is, that when the first signal handler, SIGUSR1, is run the SIGUSR2 signal is blocked. I think this is what Daniel was trying to say, or I didn't provide enough information for him to catch it. So, I've fixed the sigaction call to unblock SIGUSR2 while SIGUSR1 is going and rearranged a few things: me->stop_info.signal = 0; me->stop_info.last_stop_count = my_stop_count; /* Tell the thread that wants to stop the world that this */ /* thread has been stopped. Note that sem_post() is */ /* the only async-signal-safe primitive in LinuxThreads. */ sem_post(&GC_suspend_ack_sem); #if DEBUG_THREADS GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); #endif /* Wait until that thread tells us to restart by sending */ /* this thread a SIG_THR_RESTART signal. */ if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); # ifdef NO_SIGNALS if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); # endif while (me->stop_info.signal != SIG_THR_RESTART) { sigsuspend(&mask); /* Wait for signal */ } There might still be a bug that I'm just hiding. I think that the problem is while in the handler for SIGUSR1 and someone calls pthread_kill with SIGUSR2, the signal isn't marked as pending because it is masked off. It appears to rely on the following behavior: thread 1 calls pthread_kill for SIGUSR1. thread 2 enters SIGUSR1 handler and SIGUSR2 is masked. thread 1 calls pthread_kill for SIGUSR2. signal is set pending as it is currently masked off. thread 2 calls sigsuspend thus unblocking SIGUSR2. Signal handler for SIGUSR2 is called and then sigsuspend in SIGUSR1 handler returns. Is this correct behavior? Should a pthread_kill of a blocked signal pend or should it be dropped? Right now, I've worked around this. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:05:14 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A2BB16A4D0; Fri, 11 Jun 2004 08:05:14 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B1B43D39; Fri, 11 Jun 2004 08:05:13 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 160A6FD087; Fri, 11 Jun 2004 01:04:57 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09799-02; Fri, 11 Jun 2004 01:04:56 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 6AE25FD075; Fri, 11 Jun 2004 01:04:56 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086941096.10026.31.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:04:56 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:05:14 -0000 Variation that doesn't work: /* * test_sr.c * * Demonstrate use of signals & semaphores for suspending and * resuming threads. */ #include #include #include #include #include #include #include #include #ifndef NUM_THREADS #define NUM_THREADS 5 #endif static sem_t semaphore; static int done = 0; static pthread_t tids[NUM_THREADS]; static void errno_abort(char *msg) { printf("%s, errno %d\n", msg, errno); abort(); } static void err_abort(int status, char *msg) { printf("%s, status %d\n", msg, status); abort(); } static void sighandler1(int sig, siginfo_t *info, ucontext_t *ucp) { sigset_t mask; printf("Thread %p pausing.\n", pthread_self()); sigfillset(&mask); sigdelset(&mask, SIGUSR2); sem_post(&semaphore); sigsuspend(&mask); printf("Thread %p successfully resumed.\n", pthread_self()); } static void sighandler2(int sig, siginfo_t *info, ucontext_t *ucp) { printf("Thread %p got resume signal.\n", pthread_self()); } /* * Thread start routine to wait on a semaphore. */ static void * worker(void *arg) { int num = (int)arg; int x; num = (int)arg; x = num * 10; printf ("Thread %d starting.\n", num); while (!done) { x = x + 1; x = x - 1; } printf("Thread %d stopping.\n", num); return (NULL); } static void pause_threads(void) { int i; printf("Master: pausing all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR1); if (sem_wait(&semaphore) == -1) errno_abort("Wait on semaphore"); } } static void resume_threads(void) { int i; printf("Master: resuming all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR2); } } int main(int argc, char *argv[]) { struct sigaction act; int status; int i; if (sem_init (&semaphore, 0, 0) == -1) errno_abort ("Init semaphore"); /* Mask all signals while in the signal handler. */ sigfillset(&act.sa_mask); act.sa_flags = SA_RESTART; act.sa_handler = sighandler1; sigaction(SIGUSR1, &act, NULL); act.sa_handler = sighandler1; sigaction(SIGUSR2, &act, NULL); /* * Create some worker threads. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_create(&tids[i], NULL, worker, (void *)i); if (status != 0) err_abort (status, "Create thread"); } sleep (1); for (i = 0; i < 5; i++) { pause_threads(); resume_threads(); } done = 1; /* * Wait for all threads to complete. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_join(tids[i], NULL); if (status != 0) err_abort(status, "Join thread"); } return (0); } From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:09:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0B316A4CE; Fri, 11 Jun 2004 08:09:13 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D24243D5D; Fri, 11 Jun 2004 08:09:13 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id D25E8FD087; Fri, 11 Jun 2004 01:09:08 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28084-03; Fri, 11 Jun 2004 01:09:08 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 28657FD075; Fri, 11 Jun 2004 01:09:08 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: <1086941096.10026.31.camel@server.mcneil.com> References: <1086941096.10026.31.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086941347.10026.33.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:09:07 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:09:13 -0000 OOOPPPSSS!!!! typo. Ignore. On Fri, 2004-06-11 at 01:04, Sean McNeil wrote: > Variation that doesn't work: > > /* > * test_sr.c > * > * Demonstrate use of signals & semaphores for suspending and > * resuming threads. > */ > #include > #include > #include > #include > #include > #include > #include > #include > > #ifndef NUM_THREADS > #define NUM_THREADS 5 > #endif > > static sem_t semaphore; > static int done = 0; > static pthread_t tids[NUM_THREADS]; > > > static void > errno_abort(char *msg) > { > printf("%s, errno %d\n", msg, errno); > abort(); > } > > static void > err_abort(int status, char *msg) > { > printf("%s, status %d\n", msg, status); > abort(); > } > > static void > sighandler1(int sig, siginfo_t *info, ucontext_t *ucp) > { > sigset_t mask; > > printf("Thread %p pausing.\n", pthread_self()); > sigfillset(&mask); > sigdelset(&mask, SIGUSR2); > sem_post(&semaphore); > sigsuspend(&mask); > printf("Thread %p successfully resumed.\n", pthread_self()); > } > > static void > sighandler2(int sig, siginfo_t *info, ucontext_t *ucp) > { > printf("Thread %p got resume signal.\n", pthread_self()); > } > > /* > * Thread start routine to wait on a semaphore. > */ > static void * > worker(void *arg) > { > int num = (int)arg; > int x; > > num = (int)arg; > x = num * 10; > > printf ("Thread %d starting.\n", num); > while (!done) { > x = x + 1; > x = x - 1; > } > printf("Thread %d stopping.\n", num); > > return (NULL); > } > > static void > pause_threads(void) > { > int i; > > printf("Master: pausing all threads.\n"); > for (i = 0; i < NUM_THREADS; i++) { > pthread_kill(tids[i], SIGUSR1); > if (sem_wait(&semaphore) == -1) > errno_abort("Wait on semaphore"); > } > } > > static void > resume_threads(void) > { > int i; > > printf("Master: resuming all threads.\n"); > for (i = 0; i < NUM_THREADS; i++) { > pthread_kill(tids[i], SIGUSR2); > } > } > > int > main(int argc, char *argv[]) > { > struct sigaction act; > int status; > int i; > > if (sem_init (&semaphore, 0, 0) == -1) > errno_abort ("Init semaphore"); > > /* Mask all signals while in the signal handler. */ > sigfillset(&act.sa_mask); > act.sa_flags = SA_RESTART; > > act.sa_handler = sighandler1; > sigaction(SIGUSR1, &act, NULL); > > act.sa_handler = sighandler1; > sigaction(SIGUSR2, &act, NULL); > > /* > * Create some worker threads. > */ > for (i = 0; i < NUM_THREADS; i++) { > status = pthread_create(&tids[i], NULL, worker, (void *)i); > if (status != 0) > err_abort (status, "Create thread"); > } > > sleep (1); > > for (i = 0; i < 5; i++) { > pause_threads(); > resume_threads(); > } > > done = 1; > > /* > * Wait for all threads to complete. > */ > for (i = 0; i < NUM_THREADS; i++) { > status = pthread_join(tids[i], NULL); > if (status != 0) > err_abort(status, "Join thread"); > } > return (0); > } > > > From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:10:40 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3E1116A4CE; Fri, 11 Jun 2004 08:10:40 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4D743D39; Fri, 11 Jun 2004 08:10:40 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B8AS6x015854; Fri, 11 Jun 2004 04:10:28 -0400 (EDT) Date: Fri, 11 Jun 2004 04:10:28 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086939928.10026.26.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:10:40 -0000 On Fri, 11 Jun 2004, Sean McNeil wrote: > OK, I think I have it figured out.... > > The problem is, that when the first signal handler, SIGUSR1, is run the > SIGUSR2 signal is blocked. I think this is what Daniel was trying to ^ not > say, or I didn't provide enough information for him to catch it. So, > I've fixed the sigaction call to unblock SIGUSR2 while SIGUSR1 is going ^^^^^^^ block > and rearranged a few things: > > me->stop_info.signal = 0; > me->stop_info.last_stop_count = my_stop_count; > > /* Tell the thread that wants to stop the world that this */ > /* thread has been stopped. Note that sem_post() is */ > /* the only async-signal-safe primitive in LinuxThreads. */ > sem_post(&GC_suspend_ack_sem); > > #if DEBUG_THREADS > GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, my_thread); > #endif > > /* Wait until that thread tells us to restart by sending */ > /* this thread a SIG_THR_RESTART signal. */ > if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); > if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() failed"); > # ifdef NO_SIGNALS > if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); > if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); > # endif > > while (me->stop_info.signal != SIG_THR_RESTART) { > sigsuspend(&mask); /* Wait for signal */ > } > > There might still be a bug that I'm just hiding. I think that the > problem is while in the handler for SIGUSR1 and someone calls > pthread_kill with SIGUSR2, the signal isn't marked as pending because it > is masked off. It appears to rely on the following behavior: ^^^^^^^^^^ No, the problem is because SIGUSR2 is _not_ blocked. I read "masked off" as "blocked" (the desired behavior). If the signal handler runs, that means that the signal is not blocked. Your goal is to prevent the signal handler (for SIGUSR2) from running until sigsuspend() is hit. Once sigsuspend() is hit, then SIGUSR2 becomes unblocked, the signal handler is run, and sigsuspend() returns. > thread 1 calls pthread_kill for SIGUSR1. > thread 2 enters SIGUSR1 handler and SIGUSR2 is masked. Right! > thread 1 calls pthread_kill for SIGUSR2. signal is set pending as it is > currently masked off. Right! > thread 2 calls sigsuspend thus unblocking SIGUSR2. Signal handler for > SIGUSR2 is called and then sigsuspend in SIGUSR1 handler returns. Exactly. > Is this correct behavior? It is correct behavior as long as your masks are set up correctly. > Should a pthread_kill of a blocked signal > pend or should it be dropped? No, pthread_kill() does not pend; it is not like pthread_join(). > Right now, I've worked around this. I'm not sure what you worked around. The last few sentences are the way you want it to work, not something to work around ;-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:14:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFDD116A4CE; Fri, 11 Jun 2004 08:14:51 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49D1E43D49; Fri, 11 Jun 2004 08:14:51 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B8Eo6x017024; Fri, 11 Jun 2004 04:14:50 -0400 (EDT) Date: Fri, 11 Jun 2004 04:14:49 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086941096.10026.31.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:14:51 -0000 On Fri, 11 Jun 2004, Sean McNeil wrote: > Variation that doesn't work: Well, yeah. That's why I sent it in a form that _did_ work :-) The variation you sent back is exactly what I thought your problem could be. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:16:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8243416A4CE; Fri, 11 Jun 2004 08:16:22 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46B8743D5D; Fri, 11 Jun 2004 08:16:22 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 913F1FD087; Fri, 11 Jun 2004 01:16:20 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28084-05; Fri, 11 Jun 2004 01:16:20 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 11FADFD075; Fri, 11 Jun 2004 01:16:20 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086941779.10026.38.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:16:20 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:16:22 -0000 Now here is something odd.... If I change the program a little, it acts completely different. It actually works faster and looks correct. I don't get it. This is pretty much exactly what boehm-gc is doing. /* * test_sr.c * * Demonstrate use of signals & semaphores for suspending and * resuming threads. */ #include #include #include #include #include #include #include #include #ifndef NUM_THREADS #define NUM_THREADS 5 #endif static sem_t semaphore; static int done = 0; static pthread_t tids[NUM_THREADS]; static void errno_abort(char *msg) { printf("%s, errno %d\n", msg, errno); abort(); } static void err_abort(int status, char *msg) { printf("%s, status %d\n", msg, status); abort(); } static void sighandler1(int sig, siginfo_t *info, ucontext_t *ucp) { sigset_t mask; printf("Thread %p pausing.\n", pthread_self()); sigfillset(&mask); sigdelset(&mask, SIGUSR2); sem_post(&semaphore); sigsuspend(&mask); printf("Thread %p successfully resumed.\n", pthread_self()); } static void sighandler2(int sig, siginfo_t *info, ucontext_t *ucp) { printf("Thread %p got resume signal.\n", pthread_self()); } /* * Thread start routine to wait on a semaphore. */ static void * worker(void *arg) { int num = (int)arg; int x; num = (int)arg; x = num * 10; printf ("Thread %d starting.\n", num); while (!done) { x = x + 1; x = x - 1; } printf("Thread %d stopping.\n", num); return (NULL); } static void pause_threads(void) { int i; printf("Master: pausing all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR1); } for (i = 0; i < NUM_THREADS; i++) { if (sem_wait(&semaphore) == -1) errno_abort("Wait on semaphore"); } } static void resume_threads(void) { int i; printf("Master: resuming all threads.\n"); for (i = 0; i < NUM_THREADS; i++) { pthread_kill(tids[i], SIGUSR2); } } int main(int argc, char *argv[]) { struct sigaction act; int status; int i; if (sem_init (&semaphore, 0, 0) == -1) errno_abort ("Init semaphore"); /* Mask all signals while in the signal handler. */ sigfillset(&act.sa_mask); act.sa_flags = SA_RESTART; act.sa_handler = sighandler1; sigaction(SIGUSR1, &act, NULL); act.sa_handler = sighandler2; sigaction(SIGUSR2, &act, NULL); /* * Create some worker threads. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_create(&tids[i], NULL, worker, (void *)i); if (status != 0) err_abort (status, "Create thread"); } sleep (1); for (i = 0; i < 5; i++) { pause_threads(); resume_threads(); } done = 1; /* * Wait for all threads to complete. */ for (i = 0; i < NUM_THREADS; i++) { status = pthread_join(tids[i], NULL); if (status != 0) err_abort(status, "Join thread"); } return (0); } From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:24:35 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D09B916A4CE for ; Fri, 11 Jun 2004 08:24:35 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B8943D31 for ; Fri, 11 Jun 2004 08:24:33 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA9062; Fri, 11 Jun 2004 16:24:10 +0800 Message-ID: <40C96CCA.9060704@freebsd.org> Date: Fri, 11 Jun 2004 16:26:50 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:24:35 -0000 This proves thread programming is so complicate, it is no longer streamline. ;-) David Xu Daniel Eischen wrote: > On Fri, 11 Jun 2004, Sean McNeil wrote: > > >>OK, I think I have it figured out.... >> >>The problem is, that when the first signal handler, SIGUSR1, is run > > the > >>SIGUSR2 signal is blocked. I think this is what Daniel was trying to > > ^ not > > >>say, or I didn't provide enough information for him to catch it. So, >>I've fixed the sigaction call to unblock SIGUSR2 while SIGUSR1 is > > going > ^^^^^^^ block > > >>and rearranged a few things: >> >> me->stop_info.signal = 0; >> me->stop_info.last_stop_count = my_stop_count; >> >> /* Tell the thread that wants to stop the world that this */ >> /* thread has been stopped. Note that sem_post() is */ >> /* the only async-signal-safe primitive in LinuxThreads. */ >> sem_post(&GC_suspend_ack_sem); >> >>#if DEBUG_THREADS >> GC_printf2("Waiting for restart #%d of 0x%lx\n", my_stop_count, > > my_thread); > >>#endif >> >> /* Wait until that thread tells us to restart by sending */ >> /* this thread a SIG_THR_RESTART signal. */ >> if (sigfillset(&mask) != 0) ABORT("sigfillset() failed"); >> if (sigdelset(&mask, SIG_THR_RESTART) != 0) ABORT("sigdelset() > > failed"); > >># ifdef NO_SIGNALS >> if (sigdelset(&mask, SIGINT) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGQUIT) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGTERM) != 0) ABORT("sigdelset() failed"); >> if (sigdelset(&mask, SIGABRT) != 0) ABORT("sigdelset() failed"); >># endif >> >> while (me->stop_info.signal != SIG_THR_RESTART) { >> sigsuspend(&mask); /* Wait for signal */ >> } >> >>There might still be a bug that I'm just hiding. I think that the >>problem is while in the handler for SIGUSR1 and someone calls >>pthread_kill with SIGUSR2, the signal isn't marked as pending because > > it > >>is masked off. It appears to rely on the following behavior: > > ^^^^^^^^^^ > > No, the problem is because SIGUSR2 is _not_ blocked. I read > "masked off" as "blocked" (the desired behavior). If the > signal handler runs, that means that the signal is not blocked. > Your goal is to prevent the signal handler (for SIGUSR2) from > running until sigsuspend() is hit. Once sigsuspend() is hit, > then SIGUSR2 becomes unblocked, the signal handler is run, > and sigsuspend() returns. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:27:16 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3921116A4CE; Fri, 11 Jun 2004 08:27:16 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFBFE43D45; Fri, 11 Jun 2004 08:27:15 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B8R16x021762; Fri, 11 Jun 2004 04:27:01 -0400 (EDT) Date: Fri, 11 Jun 2004 04:27:01 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086941779.10026.38.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:27:16 -0000 On Fri, 11 Jun 2004, Sean McNeil wrote: > Now here is something odd.... > > If I change the program a little, it acts completely different. It > actually works faster and looks correct. I don't get it. This is > pretty much exactly what boehm-gc is doing. > > static void > pause_threads(void) > { > int i; > > printf("Master: pausing all threads.\n"); > for (i = 0; i < NUM_THREADS; i++) { > pthread_kill(tids[i], SIGUSR1); > } > for (i = 0; i < NUM_THREADS; i++) { > if (sem_wait(&semaphore) == -1) > errno_abort("Wait on semaphore"); > } > } Yeah, I almost coded it this way. It seems to work faster because the threads are true workers. They're spinning wasting the CPU. The timeslice is 10 or 20 msec, so you have to wait for each thread to get timesliced out in order for it to have the signal delivered. Instead of: thread 1 spin for 10msec master kill thread 1 master wait thread for thread 1 thread 2 spin for 10msec thread 3 spin for 10msec thread 4 spin for 10msec thread 5 spin for 10msec master wakeup from thread 1 master kill thread 2 thread 3 spin for 10msec thread 4 spin for 10msec thread 5 spin for 10msec master wakeup from thread 2 master kill thread 3 ... you have threads running master thread gets his chance master kill thread 1 master kill thread 2 master kill thread 3 master kill thread 4 master kill thread 5 thread 1 swapped back in, gets signal, pauses thread 2 swapped back in, gets signal, pauses thread 3 swapped back in, gets signal, pauses thread 4 swapped back in, gets signal, pauses thread 5 swapped back in, gets signal, pauses -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:28:58 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC9EF16A4CE; Fri, 11 Jun 2004 08:28:58 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDE7B43D54; Fri, 11 Jun 2004 08:28:58 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 917A3FD087; Fri, 11 Jun 2004 01:28:40 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28084-07; Fri, 11 Jun 2004 01:28:40 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 3894DFD012; Fri, 11 Jun 2004 01:28:40 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086942520.10026.41.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:28:40 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:28:59 -0000 > No, the problem is because SIGUSR2 is _not_ blocked. I read > "masked off" as "blocked" (the desired behavior). If the > signal handler runs, that means that the signal is not blocked. > Your goal is to prevent the signal handler (for SIGUSR2) from > running until sigsuspend() is hit. Once sigsuspend() is hit, > then SIGUSR2 becomes unblocked, the signal handler is run, > and sigsuspend() returns. This is exactly what boehm-gc is doing. There must be something else lurking in here that I've missed. I have to keep looking at it. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:32:28 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EA3A16A4CE; Fri, 11 Jun 2004 08:32:28 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C94A943D2D; Fri, 11 Jun 2004 08:32:27 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B8W96x023473; Fri, 11 Jun 2004 04:32:09 -0400 (EDT) Date: Fri, 11 Jun 2004 04:32:09 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <40C96CCA.9060704@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sean McNeil cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:32:28 -0000 On Fri, 11 Jun 2004, David Xu wrote: > > This proves thread programming is so complicate, it is no longer > streamline. ;-) It's even harder trying to explain it! -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:34:56 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E510E16A4CE; Fri, 11 Jun 2004 08:34:56 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A60C343D45; Fri, 11 Jun 2004 08:34:56 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B8Ye6x024115; Fri, 11 Jun 2004 04:34:40 -0400 (EDT) Date: Fri, 11 Jun 2004 04:34:40 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086942520.10026.41.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:34:57 -0000 On Fri, 11 Jun 2004, Sean McNeil wrote: > > > No, the problem is because SIGUSR2 is _not_ blocked. I read > > "masked off" as "blocked" (the desired behavior). If the > > signal handler runs, that means that the signal is not blocked. > > Your goal is to prevent the signal handler (for SIGUSR2) from > > running until sigsuspend() is hit. Once sigsuspend() is hit, > > then SIGUSR2 becomes unblocked, the signal handler is run, > > and sigsuspend() returns. > > This is exactly what boehm-gc is doing. There must be something else > lurking in here that I've missed. I have to keep looking at it. Put print statements just before the sigsuspend() as well as keeping it in the signal handler for SIGUSR2. If you see the print from SIGUSR2 handler before you see the one from just before sigsuspend(), you know that the signal mask is not correct when SIGUSR1 is handled. Signing off for tonight... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 08:37:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C4EE16A4CE; Fri, 11 Jun 2004 08:37:59 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B24D43D53; Fri, 11 Jun 2004 08:37:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 8309FFD087; Fri, 11 Jun 2004 01:37:42 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09799-08; Fri, 11 Jun 2004 01:37:42 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 07CC4FD012; Fri, 11 Jun 2004 01:37:41 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086943061.10026.45.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 01:37:41 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 08:37:59 -0000 On Fri, 2004-06-11 at 01:34, Daniel Eischen wrote: > On Fri, 11 Jun 2004, Sean McNeil wrote: > > > > > > No, the problem is because SIGUSR2 is _not_ blocked. I read > > > "masked off" as "blocked" (the desired behavior). If the > > > signal handler runs, that means that the signal is not blocked. > > > Your goal is to prevent the signal handler (for SIGUSR2) from > > > running until sigsuspend() is hit. Once sigsuspend() is hit, > > > then SIGUSR2 becomes unblocked, the signal handler is run, > > > and sigsuspend() returns. > > > > This is exactly what boehm-gc is doing. There must be something else > > lurking in here that I've missed. I have to keep looking at it. > > Put print statements just before the sigsuspend() as well as > keeping it in the signal handler for SIGUSR2. If you see > the print from SIGUSR2 handler before you see the one from > just before sigsuspend(), you know that the signal mask > is not correct when SIGUSR1 is handled. > > Signing off for tonight... I think I may have it. I think the sigsuspend is releasing before the signal handler is executed so that the SIGUSR1 handler just loops and waits for the signal again. There may also be an optimization problem with the loop test not being volatile. Checking both posibilities now. Thanks for all the help. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 09:28:58 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95E5316A4CE; Fri, 11 Jun 2004 09:28:58 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B78A43D2D; Fri, 11 Jun 2004 09:28:58 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 4F7D0FD090; Fri, 11 Jun 2004 02:28:36 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99176-01; Fri, 11 Jun 2004 02:28:35 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 09119FD087; Fri, 11 Jun 2004 02:28:35 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: <1086944114.76446.5.camel@server.mcneil.com> References: <1086944114.76446.5.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086946114.76446.16.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 02:28:34 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 09:28:59 -0000 Sorry for top-posting, but it may be easier to read this way.... The program below has an optimization bug in that done isn't declare volatile. With that fixed, it works just fine. I've been attempting to get boehm-gc working and it seems OK with libc_r, but fails with libpthread. It is essentially doing what the program below does, but for some reason it gets stuck. Has anyone else been experimenting with boehm-gc? Also, it would really help if I had a debugger that worked with kse threads. How is that going? Tracking down pthread issues right now has been difficult with the current debugger. Can anyone throw some patches my way that may help? On Fri, 2004-06-11 at 01:55, Sean McNeil wrote: > (I've cc'd the amd64 list so here is some background) > > I'm experiencing some odd behavior with signals and threads. Daniel has > managed to isolate it to an example program that works. Except.... > > OK, so maybe this is an optimization bug. The following works fine with > no optimization, but with -O or -O2 it fails on an amd64. Can someone > test with various optimizations on i386? > > Compiled with > > cc -o test_sr test_sr.c -pthread > works > > cc -O -o test_sr test_sr.c -pthread > or > cc -O2 -o test_sr test_sr.c -pthread > hangs > > /* > * test_sr.c > * > * Demonstrate use of signals & semaphores for suspending and > * resuming threads. > */ > #include > #include > #include > #include > #include > #include > #include > #include > > #ifndef NUM_THREADS > #define NUM_THREADS 5 > #endif > > static sem_t semaphore; > static int done = 0; > static pthread_t tids[NUM_THREADS]; > > static void > errno_abort(char *msg) > { > printf("%s, errno %d\n", msg, errno); > abort(); > } > > static void > err_abort(int status, char *msg) > { > printf("%s, status %d\n", msg, status); > abort(); > } > > static void > sighandler1(int sig, siginfo_t *info, ucontext_t *ucp) > { > sigset_t mask; > int i; > pthread_t self = pthread_self(); > > for (i=0; i > printf("Thread %d pausing.\n", i); > sem_post(&semaphore); > > sigfillset(&mask); > sigdelset(&mask, SIGUSR2); > sigsuspend(&mask); > printf("Thread %d successfully resumed.\n", i); > } > > static void > sighandler2(int sig, siginfo_t *info, ucontext_t *ucp) > { > int i; > pthread_t self = pthread_self(); > > for (i=0; i > printf("Thread %d got resume signal.\n", i); > } > > /* > * Thread start routine to wait on a semaphore. > */ > static void * > worker(void *arg) > { > int num = (int)arg; > int x; > > num = (int)arg; > x = num * 10; > > printf ("Thread %d starting.\n", num); > while (!done) { > x = x + 1; > x = x - 1; > } > printf("Thread %d stopping.\n", num); > > return (NULL); > } > > static void > pause_threads(void) > { > int i; > > printf("Master: pausing all threads.\n"); > for (i = 0; i < NUM_THREADS; i++) { > pthread_kill(tids[i], SIGUSR1); > } > for (i = 0; i < NUM_THREADS; i++) { > if (sem_wait(&semaphore) == -1) > errno_abort("Wait on semaphore"); > } > } > > static void > resume_threads(void) > { > int i; > > printf("Master: resuming all threads.\n"); > for (i = 0; i < NUM_THREADS; i++) { > pthread_kill(tids[i], SIGUSR2); > } > } > > static void * > pause_resume(void *arg) > { > int i; > > for (i = 0; i < 5; i++) { > pause_threads(); > resume_threads(); > } > > return NULL; > } > > int > main(int argc, char *argv[]) > { > pthread_t prid; > struct sigaction act; > int status; > int i; > > if (sem_init (&semaphore, 0, 0) == -1) > errno_abort ("Init semaphore"); > > /* Mask all signals while in the signal handler. */ > sigfillset(&act.sa_mask); > act.sa_flags = SA_RESTART; > > act.sa_handler = sighandler1; > sigaction(SIGUSR1, &act, NULL); > > act.sa_handler = sighandler2; > sigaction(SIGUSR2, &act, NULL); > > /* > * Create some worker threads. > */ > for (i = 0; i < NUM_THREADS; i++) { > status = pthread_create(&tids[i], NULL, worker, (void > *)i); > if (status != 0) > err_abort (status, "Create thread"); > } > > pthread_create (&prid, NULL, pause_resume, NULL); > pthread_join(prid, NULL); > > for (i = 0; i < 5; i++) { > pause_threads(); > resume_threads(); > } > > done = 1; > > /* > * Wait for all threads to complete. > */ > for (i = 0; i < NUM_THREADS; i++) { > status = pthread_join(tids[i], NULL); > if (status != 0) > err_abort(status, "Join thread"); > } > return (0); > } > From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 14:28:31 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEE3616A4D0; Fri, 11 Jun 2004 14:28:31 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F9D843D49; Fri, 11 Jun 2004 14:28:31 +0000 (GMT) (envelope-from ru@FreeBSD.org) Received: from freefall.freebsd.org (ru@localhost [127.0.0.1]) i5BESVpc005902; Fri, 11 Jun 2004 14:28:31 GMT (envelope-from ru@freefall.freebsd.org) Received: (from ru@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5BESV6H005898; Fri, 11 Jun 2004 14:28:31 GMT (envelope-from ru) Date: Fri, 11 Jun 2004 14:28:31 GMT From: Ruslan Ermilov Message-Id: <200406111428.i5BESV6H005898@freefall.freebsd.org> To: root@shandritokkel.homeunix.org, ru@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/50733: buildworld won't build, because of linking problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 14:28:31 -0000 Synopsis: buildworld won't build, because of linking problem State-Changed-From-To: analyzed->closed State-Changed-By: ru State-Changed-When: Fri Jun 11 14:27:59 GMT 2004 State-Changed-Why: No indication of interest looking into this issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=50733 From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 14:42:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DC0E16A4CE; Fri, 11 Jun 2004 14:42:44 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147BB43D5E; Fri, 11 Jun 2004 14:42:44 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i5BEgKxY006662; Fri, 11 Jun 2004 14:42:24 GMT (envelope-from davidxu@freebsd.org) Message-ID: <40C9C465.5080305@freebsd.org> Date: Fri, 11 Jun 2004 22:40:37 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040522 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> In-Reply-To: <1086946114.76446.16.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 14:42:44 -0000 Sean McNeil wrote: >Sorry for top-posting, but it may be easier to read this way.... > >The program below has an optimization bug in that done isn't declare >volatile. With that fixed, it works just fine. I've been attempting to >get boehm-gc working and it seems OK with libc_r, but fails with >libpthread. It is essentially doing what the program below does, but >for some reason it gets stuck. Has anyone else been experimenting with >boehm-gc? > >Also, it would really help if I had a debugger that worked with kse >threads. How is that going? Tracking down pthread issues right now has >been difficult with the current debugger. Can anyone throw some patches >my way that may help? > > Please try the patch: http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, I believe I caught a bug in the sigsuspend(), thread should scan pending signals first, only when there is no pending signal in wait set, the thread can sleep. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 17:43:03 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C85916A4D0; Fri, 11 Jun 2004 17:43:03 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14FB543D1D; Fri, 11 Jun 2004 17:43:01 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id AC692FD087; Fri, 11 Jun 2004 10:42:34 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68545-06; Fri, 11 Jun 2004 10:42:34 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 4206DFD059; Fri, 11 Jun 2004 10:42:34 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40C9C465.5080305@freebsd.org> References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> Content-Type: text/plain Message-Id: <1086975754.69031.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 10:42:34 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 17:43:03 -0000 On Fri, 2004-06-11 at 07:40, David Xu wrote: > Sean McNeil wrote: > > >Sorry for top-posting, but it may be easier to read this way.... > > > >The program below has an optimization bug in that done isn't declare > >volatile. With that fixed, it works just fine. I've been attempting to > >get boehm-gc working and it seems OK with libc_r, but fails with > >libpthread. It is essentially doing what the program below does, but > >for some reason it gets stuck. Has anyone else been experimenting with > >boehm-gc? > > > >Also, it would really help if I had a debugger that worked with kse > >threads. How is that going? Tracking down pthread issues right now has > >been difficult with the current debugger. Can anyone throw some patches > >my way that may help? > > > > > Please try the patch: > http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff > > the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, > I believe I caught a bug in the sigsuspend(), thread > should scan pending signals first, only when there is > no pending signal in wait set, the thread can sleep. > > David Xu This patch makes sigsuspend work, but there is still something missing. The actual signal handler is not getting called so I sit in an infinite loop waiting for the signal handler to set something. From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 18:09:01 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C82516A4E4; Fri, 11 Jun 2004 18:09:01 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25EC843D46; Fri, 11 Jun 2004 18:09:01 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id B8E72FD087; Fri, 11 Jun 2004 11:08:54 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68545-08; Fri, 11 Jun 2004 11:08:54 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 52DA1FD071; Fri, 11 Jun 2004 11:08:54 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40C9C465.5080305@freebsd.org> References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> Content-Type: text/plain Message-Id: <1086977334.70017.1.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 11:08:54 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 18:09:01 -0000 On Fri, 2004-06-11 at 07:40, David Xu wrote: > Sean McNeil wrote: > > >Sorry for top-posting, but it may be easier to read this way.... > > > >The program below has an optimization bug in that done isn't declare > >volatile. With that fixed, it works just fine. I've been attempting to > >get boehm-gc working and it seems OK with libc_r, but fails with > >libpthread. It is essentially doing what the program below does, but > >for some reason it gets stuck. Has anyone else been experimenting with > >boehm-gc? > > > >Also, it would really help if I had a debugger that worked with kse > >threads. How is that going? Tracking down pthread issues right now has > >been difficult with the current debugger. Can anyone throw some patches > >my way that may help? > > > > > Please try the patch: > http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff > > the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, > I believe I caught a bug in the sigsuspend(), thread > should scan pending signals first, only when there is > no pending signal in wait set, the thread can sleep. The following alternative patch worked for me: http://mcneil.com/~sean/thr_sigsuspend.c.diff From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 18:15:39 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04C5416A4CE; Fri, 11 Jun 2004 18:15:39 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA68F43D49; Fri, 11 Jun 2004 18:15:38 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 9F908FD087; Fri, 11 Jun 2004 11:15:38 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68545-10; Fri, 11 Jun 2004 11:15:38 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 39096FD071; Fri, 11 Jun 2004 11:15:38 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40C9C465.5080305@freebsd.org> References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> Content-Type: text/plain Message-Id: <1086977738.70017.9.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 11:15:38 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 18:15:39 -0000 On Fri, 2004-06-11 at 07:40, David Xu wrote: > Sean McNeil wrote: > > >Sorry for top-posting, but it may be easier to read this way.... > > > >The program below has an optimization bug in that done isn't declare > >volatile. With that fixed, it works just fine. I've been attempting to > >get boehm-gc working and it seems OK with libc_r, but fails with > >libpthread. It is essentially doing what the program below does, but > >for some reason it gets stuck. Has anyone else been experimenting with > >boehm-gc? > > > >Also, it would really help if I had a debugger that worked with kse > >threads. How is that going? Tracking down pthread issues right now has > >been difficult with the current debugger. Can anyone throw some patches > >my way that may help? > > > > > Please try the patch: > http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff > > the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, > I believe I caught a bug in the sigsuspend(), thread > should scan pending signals first, only when there is > no pending signal in wait set, the thread can sleep. Also, the mask provided by the sigsuspend call should govern what handlers get called. So the sigmask should be left in place until after the _thr_sig_check_pending(curthread) call. Thanks for catching this :) Sean From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 18:54:19 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6C7416A4CE for ; Fri, 11 Jun 2004 18:54:19 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B1043D1F for ; Fri, 11 Jun 2004 18:54:19 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 56A09FD075 for ; Fri, 11 Jun 2004 11:54:03 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70084-02 for ; Fri, 11 Jun 2004 11:54:03 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DCCBBFD01A for ; Fri, 11 Jun 2004 11:54:02 -0700 (PDT) From: Sean McNeil To: freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086980042.70219.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 11:54:02 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: gdb patches - can I get them? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 18:54:19 -0000 I asked in a completely unrelated about this, but realized it might not be seen by the right people. I was wondering if there were patches to gdb for kse support that I could get my hands on. I'm debugging some issues that would be easier to track down with the support of kse in gdb. Sean From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 22:35:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 678C716A4CE; Fri, 11 Jun 2004 22:35:22 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D3AA43D31; Fri, 11 Jun 2004 22:35:22 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i5BMYUMu066113; Fri, 11 Jun 2004 22:34:31 GMT (envelope-from davidxu@freebsd.org) Message-ID: <40CA330F.5090103@freebsd.org> Date: Sat, 12 Jun 2004 06:32:47 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040522 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> <1086977738.70017.9.camel@server.mcneil.com> In-Reply-To: <1086977738.70017.9.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 22:35:22 -0000 Sean McNeil wrote: >On Fri, 2004-06-11 at 07:40, David Xu wrote: > > >>Sean McNeil wrote: >> >> >> >>>Sorry for top-posting, but it may be easier to read this way.... >>> >>>The program below has an optimization bug in that done isn't declare >>>volatile. With that fixed, it works just fine. I've been attempting to >>>get boehm-gc working and it seems OK with libc_r, but fails with >>>libpthread. It is essentially doing what the program below does, but >>>for some reason it gets stuck. Has anyone else been experimenting with >>>boehm-gc? >>> >>>Also, it would really help if I had a debugger that worked with kse >>>threads. How is that going? Tracking down pthread issues right now has >>>been difficult with the current debugger. Can anyone throw some patches >>>my way that may help? >>> >>> >>> >>> >>Please try the patch: >>http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff >> >>the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, >>I believe I caught a bug in the sigsuspend(), thread >>should scan pending signals first, only when there is >>no pending signal in wait set, the thread can sleep. >> >> > >Also, the mask provided by the sigsuspend call should govern what >handlers get called. So the sigmask should be left in place until after >the _thr_sig_check_pending(curthread) call. > >Thanks for catching this :) > >Sean > > > > > > No the patch is still not correct, before _thr_sched_switch_unlocked(curthread) returns, signal will be delivered, so there needs a flag to tell signal dispatching code to use old signal mask when delivering signal to signal handler. I am working on it, thanks for your patch. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 23:05:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C5C716A4CE; Fri, 11 Jun 2004 23:05:15 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB1343D1F; Fri, 11 Jun 2004 23:05:15 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 77C8FFD03A; Fri, 11 Jun 2004 15:40:33 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31385-03; Fri, 11 Jun 2004 15:40:33 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id F16F9FD031; Fri, 11 Jun 2004 15:40:32 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40CA330F.5090103@freebsd.org> References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <1086977738.70017.9.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org> Content-Type: text/plain Message-Id: <1086993632.45971.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 15:40:32 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 23:05:15 -0000 On Fri, 2004-06-11 at 15:32, David Xu wrote: > Sean McNeil wrote: > > >On Fri, 2004-06-11 at 07:40, David Xu wrote: > > > > > >>Sean McNeil wrote: > >> > >> > >> > >>>Sorry for top-posting, but it may be easier to read this way.... > >>> > >>>The program below has an optimization bug in that done isn't declare > >>>volatile. With that fixed, it works just fine. I've been attempting to > >>>get boehm-gc working and it seems OK with libc_r, but fails with > >>>libpthread. It is essentially doing what the program below does, but > >>>for some reason it gets stuck. Has anyone else been experimenting with > >>>boehm-gc? > >>> > >>>Also, it would really help if I had a debugger that worked with kse > >>>threads. How is that going? Tracking down pthread issues right now has > >>>been difficult with the current debugger. Can anyone throw some patches > >>>my way that may help? > >>> > >>> > >>> > >>> > >>Please try the patch: > >>http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff > >> > >>the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, > >>I believe I caught a bug in the sigsuspend(), thread > >>should scan pending signals first, only when there is > >>no pending signal in wait set, the thread can sleep. > >> > >> > > > >Also, the mask provided by the sigsuspend call should govern what > >handlers get called. So the sigmask should be left in place until after > >the _thr_sig_check_pending(curthread) call. > > > >Thanks for catching this :) > > > >Sean > > > > > > > > > > > > > No the patch is still not correct, before > _thr_sched_switch_unlocked(curthread) returns, signal will be delivered, > so there needs a flag to tell signal dispatching code to use old signal mask > when delivering signal to signal handler. I am working on it, > thanks for your patch. What old signal mask? It should be the signals that sigsuspend allows that get handled within sigsuspend. Make sure the following can still happen: signal is masked. sigsuspend is called with signal unmasked. signal comes in or is pending already. signal handler is called. sigsuspend returns. Sean From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 23:24:28 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 458CD16A4CE; Fri, 11 Jun 2004 23:24:28 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24CFA43D1D; Fri, 11 Jun 2004 23:24:28 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i5BNO6MY071810; Fri, 11 Jun 2004 23:24:07 GMT (envelope-from davidxu@freebsd.org) Message-ID: <40CA3EAF.70508@freebsd.org> Date: Sat, 12 Jun 2004 07:22:23 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040522 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40C9C465.5080305@freebsd.org> <1086977738.70017.9.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org> <1086993632.45971.2.camel@server.mcneil.com> In-Reply-To: <1086993632.45971.2.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 23:24:28 -0000 Sean McNeil wrote: >On Fri, 2004-06-11 at 15:32, David Xu wrote: > > >>Sean McNeil wrote: >> >> >> >>>On Fri, 2004-06-11 at 07:40, David Xu wrote: >>> >>> >>> >>> >>>>Sean McNeil wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Sorry for top-posting, but it may be easier to read this way.... >>>>> >>>>>The program below has an optimization bug in that done isn't declare >>>>>volatile. With that fixed, it works just fine. I've been attempting to >>>>>get boehm-gc working and it seems OK with libc_r, but fails with >>>>>libpthread. It is essentially doing what the program below does, but >>>>>for some reason it gets stuck. Has anyone else been experimenting with >>>>>boehm-gc? >>>>> >>>>>Also, it would really help if I had a debugger that worked with kse >>>>>threads. How is that going? Tracking down pthread issues right now has >>>>>been difficult with the current debugger. Can anyone throw some patches >>>>>my way that may help? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Please try the patch: >>>>http://people.freebsd.org/~davidxu/kse/thr_sigsuspend.c.diff >>>> >>>>the patch is for file /usr/src/lib/libpthread/thread/thr_sigsuspend.c, >>>>I believe I caught a bug in the sigsuspend(), thread >>>>should scan pending signals first, only when there is >>>>no pending signal in wait set, the thread can sleep. >>>> >>>> >>>> >>>> >>>Also, the mask provided by the sigsuspend call should govern what >>>handlers get called. So the sigmask should be left in place until after >>>the _thr_sig_check_pending(curthread) call. >>> >>>Thanks for catching this :) >>> >>>Sean >>> >>> >>> >>> >>> >>> >>> >>> >>No the patch is still not correct, before >>_thr_sched_switch_unlocked(curthread) returns, signal will be delivered, >>so there needs a flag to tell signal dispatching code to use old signal mask >>when delivering signal to signal handler. I am working on it, >>thanks for your patch. >> >> > >What old signal mask? It should be the signals that sigsuspend allows >that get handled within sigsuspend. Make sure the following can still >happen: > >signal is masked. >sigsuspend is called with signal unmasked. >signal comes in or is pending already. >signal handler is called. >sigsuspend returns. > >Sean > > > > > when signal handler is called in sigsuspend(), thread signal masks is set to the signal set sigsuspend passes and ored with the signal current is being handled. uc_sigmask in ucontext is set to the signal masks before sigsuspend is called, when the signal handler is returned, uc_sigmask should be copied to thread's signal mask, then sigsuspend returns. your patch does not set uc_sigmasks correctly. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 23:37:05 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57E5816A4CE for ; Fri, 11 Jun 2004 23:37:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3941B43D39; Fri, 11 Jun 2004 23:37:05 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i5BNakeb072378; Fri, 11 Jun 2004 23:36:49 GMT (envelope-from davidxu@freebsd.org) Message-ID: <40CA41A7.9040407@freebsd.org> Date: Sat, 12 Jun 2004 07:35:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040522 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086980042.70219.12.camel@server.mcneil.com> In-Reply-To: <1086980042.70219.12.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: gdb patches - can I get them? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 23:37:05 -0000 Sean McNeil wrote: >I asked in a completely unrelated about this, but realized it might not >be seen by the right people. I was wondering if there were patches to >gdb for kse support that I could get my hands on. I'm debugging some >issues that would be easier to track down with the support of kse in >gdb. > >Sean > > > http://people.freebsd.org/~davidxu/kse/dbg/ The patch needs to be updated because julian splitted kse code from kern_thread.c, I will update it when sigsuspend bug is fixed. Note that the patch is not final, there are arguments about this patch. David Xu From owner-freebsd-threads@FreeBSD.ORG Sat Jun 12 01:01:24 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EA2416A4CE; Sat, 12 Jun 2004 01:01:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 340A143D4C; Sat, 12 Jun 2004 01:01:24 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i5C10fsN079317; Sat, 12 Jun 2004 01:00:44 GMT (envelope-from davidxu@freebsd.org) Message-ID: <40CA5552.9090900@freebsd.org> Date: Sat, 12 Jun 2004 08:58:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040522 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <1086977738.70017.9.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org> <1086993632.45971.2.camel@server.mcneil.com> In-Reply-To: <1086993632.45971.2.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 01:01:24 -0000 Sean McNeil wrote: >What old signal mask? It should be the signals that sigsuspend allows >that get handled within sigsuspend. Make sure the following can still >happen: > >signal is masked. >sigsuspend is called with signal unmasked. >signal comes in or is pending already. >signal handler is called. >sigsuspend returns. > >Sean > > please try : http://people.freebsd.org/~davidxu/kse/sigsuspend.diff David Xu From owner-freebsd-threads@FreeBSD.ORG Sat Jun 12 01:17:37 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E019716A4CE; Sat, 12 Jun 2004 01:17:37 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E46D43D48; Sat, 12 Jun 2004 01:17:37 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id A8FA3FD087; Fri, 11 Jun 2004 18:17:03 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05386-09; Fri, 11 Jun 2004 18:17:03 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 29524FD005; Fri, 11 Jun 2004 18:17:03 -0700 (PDT) From: Sean McNeil To: David Xu In-Reply-To: <40CA5552.9090900@freebsd.org> References: <1086944114.76446.5.camel@server.mcneil.com> <1086946114.76446.16.camel@server.mcneil.com> <40CA330F.5090103@freebsd.org><40CA5552.9090900@freebsd.org> Content-Type: text/plain Message-Id: <1087003022.95306.0.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 18:17:02 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 01:17:38 -0000 On Fri, 2004-06-11 at 17:58, David Xu wrote: > Sean McNeil wrote: > > >What old signal mask? It should be the signals that sigsuspend allows > >that get handled within sigsuspend. Make sure the following can still > >happen: > > > >signal is masked. > >sigsuspend is called with signal unmasked. > >signal comes in or is pending already. > >signal handler is called. > >sigsuspend returns. > > > >Sean > > > > > please try : > http://people.freebsd.org/~davidxu/kse/sigsuspend.diff Great job, David. Solves my issue. Cheers, Sean