From owner-freebsd-threads@FreeBSD.ORG Mon Oct 3 11:02:45 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 BA20716A420 for ; Mon, 3 Oct 2005 11:02:45 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDAC243D5F for ; Mon, 3 Oct 2005 11:02:24 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j93B2Oqp066442 for ; Mon, 3 Oct 2005 11:02:24 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j93B2NUY066436 for freebsd-threads@freebsd.org; Mon, 3 Oct 2005 11:02:23 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 Oct 2005 11:02:23 GMT Message-Id: <200510031102.j93B2NUY066436@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 11:02:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) o [2005/05/11] threads/80887threads ULE with SMP broke libpthread/libthr on 5 2 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] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/03/10] threads/78660threads Java hangs unkillably in STOP state after o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/10] threads/84778threads libpthread busy loop/hang with Java when o [2005/08/19] threads/85112threads Resource temporarily unavailable reading o [2005/08/20] threads/85160threads [patch] libobjc + libpthread/libthr crash o [2005/09/12] threads/86004threads libthr broken on amd64 29 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [PATCH] libc_r close() will fail on any f o [2005/09/12] kern/86029 threads undefined reference to `_thread_dump_info 14 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 3 15:16:08 2005 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org 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 9FC5616A41F for ; Mon, 3 Oct 2005 15:16:08 +0000 (GMT) (envelope-from pascal.gloor@spale.com) Received: from asgard.spale.com (asgard.spale.com [62.220.132.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A0243D49 for ; Mon, 3 Oct 2005 15:16:04 +0000 (GMT) (envelope-from pascal.gloor@spale.com) Received: from pc-pgloor.lan.intra (e3-1.lanservices.bie05.lan.ch [212.60.62.84]) by asgard.spale.com (Postfix) with ESMTP id EF6FB30D932 for ; Mon, 3 Oct 2005 17:16:02 +0200 (CEST) From: Pascal Gloor To: freebsd-threads@FreeBSD.org Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-unEUCMhPCsUu/nNBWqZ9" Date: Mon, 03 Oct 2005 17:16:02 +0200 Message-Id: <1128352562.7600.17.camel@ubuntu.lan.intra> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Cc: Subject: Problem Report bin/32295 : pthread dont dequeue signals X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 15:16:08 -0000 --=-unEUCMhPCsUu/nNBWqZ9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi there, I'm wondering why this patch has not yet been applied? its quite important as it affects almost every mysql user using pthreads. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D32295 Regards, Pascal --=-unEUCMhPCsUu/nNBWqZ9 Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/TCCAtkw ggJCoAMCAQICAw7UBTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjAxMTE1NTM5WhcNMDYwNjAxMTE1NTM5WjBIMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSUwIwYJKoZIhvcNAQkBFhZwYXNjYWwuZ2xvb3JAc3Bh bGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjZo4z93WRba5xnlAQwK8kUW pRpwgPik8RppR/XhngMVXQrlcfzt52y8taykiy9xLV8JKotfAQrnTywQPzjC4+uoXL5blu02HvNO 8t7G3ELlGdEkls4AhX0U3r04q9tmqsiNEdk12IEoDi4NGBYmYNLA3j1w59p63Px9yCciPy/PnKaN OHAxGDjppHM+9tCnbejG6X8MOCqAIi2VXkWuufObyoErpXtnHiF/53GDrWhcP+cbCN8L75ZtYhf1 UYU27i0Yj7kuJGQ6430aTglbSdFJJWRT1BW3a++zSmyjoMGpABkPNaWMvhjYODTujFhirMHy3oa8 NJjA8oxP4F8d3QIDAQABozMwMTAhBgNVHREEGjAYgRZwYXNjYWwuZ2xvb3JAc3BhbGUuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAwXeUsxl/1mVWo3xmNfBcxx2jXko1DDE/MiYi m8jnPznIKUvEManpvWNa2PmPB17aorh6RqGBZUkU9b7Pz8FDzEo91PS7+JG7uxEEpclueq8n2lMk ppASBeSTpeps3SQYqG4gt3LxgGZV62ZcKIfJbHsM6Y6ObpOIv74YKFZSCJMwggLZMIICQqADAgEC AgMO1AUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMB4XDTA1MDYwMTExNTUzOVoXDTA2MDYwMTExNTUzOVowSDEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYWcGFzY2FsLmdsb29yQHNwYWxlLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK42aOM/d1kW2ucZ5QEMCvJFFqUacID4pPEa aUf14Z4DFV0K5XH87edsvLWspIsvcS1fCSqLXwEK508sED84wuPrqFy+W5btNh7zTvLextxC5RnR JJbOAIV9FN69OKvbZqrIjRHZNdiBKA4uDRgWJmDSwN49cOfaetz8fcgnIj8vz5ymjThwMRg46aRz PvbQp23oxul/DDgqgCItlV5Frrnzm8qBK6V7Zx4hf+dxg61oXD/nGwjfC++WbWIX9VGFNu4tGI+5 LiRkOuN9Gk4JW0nRSSVkU9QVt2vvs0pso6DBqQAZDzWljL4Y2Dg07oxYYqzB8t6GvDSYwPKMT+Bf Hd0CAwEAAaMzMDEwIQYDVR0RBBowGIEWcGFzY2FsLmdsb29yQHNwYWxlLmNvbTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAMF3lLMZf9ZlVqN8ZjXwXMcdo15KNQwxPzImIpvI5z85yClL xDGp6b1jWtj5jwde2qK4ekahgWVJFPW+z8/BQ8xKPdT0u/iRu7sRBKXJbnqvJ9pTJKaQEgXkk6Xq bN0kGKhuILdy8YBmVetmXCiHyWx7DOmOjm6TiL++GChWUgiTMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAz MDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1 BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fx H5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wID AQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOB gQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4 gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMO1AUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDAzMTUxNjAyWjAjBgkqhkiG9w0BCQQxFgQUR2CafIWY Nf+S+4pL93NuKP1v01YweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAw7UBTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMO1AUwDQYJKoZIhvcNAQEBBQAEggEARw5fEl0A 1PQAohLBs9WK9b6bEvo1Cu0A2pU0C4v2w87hFBw76hT83dBHa+LBwjGHaJY302jaVlItJkmljBu8 PHM1FIBeIQJEkYV4tieiRLagg/Uh2qhY3A198+2ANf/G4iAigyIBcLQ/3u1tmrDxzA5V0Twoc5pg 35b73H8j3/X26SBeQpsjGiU8ur/gxhJuyxhtG4+tA5n8S53OMagiG84VEMEZsRF532Qff/97Toi2 54K3/eVNoaPCcvvl1WzhEmtP3KJXfPep/VoQgU7nji3cdiovXn5+UrC2M/5EaPrLhK2R6mmtjV3M HTmz7FfAX/r+IDRDAwiiigU7az+KlAAAAAAAAA== --=-unEUCMhPCsUu/nNBWqZ9-- From owner-freebsd-threads@FreeBSD.ORG Wed Oct 5 06:02:54 2005 Return-Path: X-Original-To: threads@freebsd.org 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 ABB4216A41F for ; Wed, 5 Oct 2005 06:02:54 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CE2F43D49 for ; Wed, 5 Oct 2005 06:02:51 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9562b3B072003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2005 02:02:41 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by blue.virtual-estates.net (8.13.4/8.13.4/Submit) id j9562aU8072002; Wed, 5 Oct 2005 02:02:36 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) X-Authentication-Warning: blue.virtual-estates.net: mi set sender to mi+kde@aldan.algebra.com using -f From: Mikhail Teterin To: threads@freebsd.org Date: Wed, 5 Oct 2005 02:02:36 -0400 User-Agent: KMail/1.8.2 X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: jim@corebsd.or.id Subject: Non-threaded app dlopen-ing a thread-using library X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2005 06:02:54 -0000 Hello! I'm trying to improve the security/xmlsec1 port to support the nss-backend (which vendor supports, but the port does not). Nss (security/nss) use nspr (devel/nspr), which uses threads. The xmlsec1 executable, built by the security/xmlsec1 port is not multi-threaded by itself, but it is opening the specified back-ends at run-time. Do I need to make the executable itself multi-threaded -- just in case it needs to dlopen() a thread-using library, or is there a better way? Its other possible back-ends -- OpenSSL and GNUTLS -- do not use threads. Thanks! -mi From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 08:55:56 2005 Return-Path: X-Original-To: threads@freebsd.org 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 202F516A41F for ; Thu, 6 Oct 2005 08:55:56 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from mx3.uidaho.edu (mx3.uidaho.edu [129.101.155.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE35F43D49 for ; Thu, 6 Oct 2005 08:55:54 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from mailA.its.uidaho.edu (mailA.its.uidaho.edu [129.101.155.252]) by mx3.uidaho.edu (8.13.3/8.13.3) with ESMTP id j968tsBL026136 for ; Thu, 6 Oct 2005 01:55:54 -0700 Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) by mailA.its.uidaho.edu (Go Vandals!) with ESMTPA id <0INX001SXKT4P6@mailA.its.uidaho.edu> for threads@freebsd.org; Thu, 06 Oct 2005 01:55:54 -0700 (PDT) Date: Thu, 06 Oct 2005 01:55:30 -0700 From: Jason Evans In-reply-to: <200510050202.36730@aldan> To: Mikhail Teterin Message-id: MIME-version: 1.0 (Apple Message framework v734) X-Mailer: Apple Mail (2.734) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7bit References: <200510050202.36730@aldan> X-SpamDetails: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.0.0-05091301 definitions=3.0.0-05100503 X-SpamScore: 0 Cc: threads@freebsd.org, jim@corebsd.or.id Subject: Re: Non-threaded app dlopen-ing a thread-using library X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 08:55:56 -0000 On Oct 4, 2005, at 11:02 PM, Mikhail Teterin wrote: > Do I need to make the executable itself multi-threaded -- just in case > it needs to dlopen() a thread-using library, or is there a better way? > As long as the dlopen()ed library is correctly linked, your app doesn't need to explicitly link against the library's dependencies. Dependencies should get pulled in after dlopen() as necessary, on the fly, as a result of the dlopen()ed library's dependencies. There's nothing magical about a threaded app, as compared to a non- threaded app. The first time a pthreads API is called, libpthread initializes itself. It's fine if this happens as the result of executing dlopen()ed code; the only issue is making sure that the library dependencies are set up correctly. Jason From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 11:15:09 2005 Return-Path: X-Original-To: threads@FreeBSD.org 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 CFFFF16A44C for ; Thu, 6 Oct 2005 11:15:09 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A75343D46 for ; Thu, 6 Oct 2005 11:15:09 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id D44FD46B1A for ; Thu, 6 Oct 2005 07:15:08 -0400 (EDT) Date: Thu, 6 Oct 2005 12:15:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: threads@FreeBSD.org Message-ID: <20051006121233.D84936@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1666198623-1128597308=:84936" Cc: Subject: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 11:15:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1666198623-1128597308=:84936 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed I was writing test tools yesterday, and was a bit surprised to find that hitting ctrl-T interrupts connect() for applications linked against libpthread(). I wrote a simple test tool and found that this is not the case for any of the other thread libraries (which seems correct to me). Test tool attached: peppercorn:~/tmp/connect> ./connect 192.168.100.203 80 Connecting to 192.168.100.203:80 load: 0.00 cmd: connect 54400 [runnable] 0.00u 0.00s 0% 972k ^C peppercorn:~/tmp/connect> ./connect_libthr 192.168.100.203 80 Connecting to 192.168.100.203:80 load: 0.00 cmd: connect_libthr 54399 [connec] 0.00u 0.00s 0% 740k ^C peppercorn:~/tmp/connect> ./connect_libpthread 192.168.100.203 80 Connecting to 192.168.100.203:80 load: 0.00 cmd: connect_libpthread 54401 [runnable] 0.00u 0.00s 0% 844k connect_libpthread: connect(192.168.100.203 80): Interrupted system call peppercorn:~/tmp/connect> ./connect_libc_r 192.168.100.203 80 Connecting to 192.168.100.203:80 load: 0.00 cmd: connect_libc_r 54402 [runnable] 0.00u 0.00s 0% 972k ^C (note the importance of running the connect tool against an IP that won't respond, or you will connect rather than blocking) Robert N M Watson --0-1666198623-1128597308=:84936 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile Content-Transfer-Encoding: BASE64 Content-ID: <20051006121508.M84936@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=Makefile YWxsOiBjb25uZWN0IGNvbm5lY3RfbGlidGhyIGNvbm5lY3RfbGlicHRocmVh ZCBjb25uZWN0X2xpYmNfcg0KDQpjb25uZWN0OiBjb25uZWN0LmMNCglnY2Mg LVdhbGwgLW8gY29ubmVjdCBjb25uZWN0LmMNCg0KY29ubmVjdF9saWJ0aHI6 IGNvbm5lY3QuYw0KCWdjYyAtV2FsbCAtbyBjb25uZWN0X2xpYnRociBjb25u ZWN0LmMgLWx0aHINCg0KY29ubmVjdF9saWJwdGhyZWFkOiBjb25uZWN0LmMN CglnY2MgLVdhbGwgLW8gY29ubmVjdF9saWJwdGhyZWFkIGNvbm5lY3QuYyAt bHB0aHJlYWQNCg0KY29ubmVjdF9saWJjX3I6IGNvbm5lY3QuYw0KCWdjYyAt V2FsbCAtbyBjb25uZWN0X2xpYmNfciBjb25uZWN0LmMgLWxjX3INCg0KDQo= --0-1666198623-1128597308=:84936 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=connect.c Content-Transfer-Encoding: BASE64 Content-ID: <20051006121508.E84936@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=connect.c LyotDQogKiBDb3B5cmlnaHQgKGMpIDIwMDUgUm9iZXJ0IE4uIE0uIFdhdHNv bg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAqDQogKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBw cm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucw0KICogYXJl IG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIuDQogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAg bm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQ0KICogICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3Ry aWJ1dGlvbi4NCiAqDQogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5EDQog KiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUNCiAqIElNUExJRUQgV0FSUkFO VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUiBQVVJQT1NFDQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM RQ0KICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwNCiAqIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTDQogKiBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ VElPTikNCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUDQogKiBM SUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9U SEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZDQogKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GDQogKiBTVUNIIERBTUFHRS4NCiAqDQogKiAkRnJlZUJT RCQNCiAqLw0KDQojaW5jbHVkZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8 c3lzL3NvY2tldC5oPg0KDQojaW5jbHVkZSA8bmV0aW5ldC9pbi5oPg0KDQoj aW5jbHVkZSA8YXJwYS9pbmV0Lmg+DQoNCiNpbmNsdWRlIDxlcnIuaD4NCiNp bmNsdWRlIDxwdGhyZWFkLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNs dWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0KaW50DQpt YWluKGludCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQoJc3RydWN0IHNvY2th ZGRyX2luIHNpbjsNCglpbnQgc29jazsNCg0KCWlmIChhcmdjICE9IDMpDQoJ CWVycngoLTEsICJ1c2FnZTogY29ubmVjdCBbaXBdIFtwb3J0XSIpOw0KDQoJ Ynplcm8oJnNpbiwgc2l6ZW9mKHNpbikpOw0KCXNpbi5zaW5fbGVuID0gc2l6 ZW9mKHNpbik7DQoJc2luLnNpbl9mYW1pbHkgPSBBRl9JTkVUOw0KCXNpbi5z aW5fYWRkci5zX2FkZHIgPSBpbmV0X2FkZHIoYXJndlsxXSk7DQoJc2luLnNp bl9wb3J0ID0gaHRvbnMoYXRvaShhcmd2WzJdKSk7DQoNCglzb2NrID0gc29j a2V0KFBGX0lORVQsIFNPQ0tfU1RSRUFNLCAwKTsNCglpZiAoc29jayA8IDAp DQoJCWVycigtMSwgInNvY2tldChQRl9JTkVULCBTT0NLX1NUUkVBTSwgMCki KTsNCg0KCXByaW50ZigiQ29ubmVjdGluZyB0byAlczolZFxuIiwgaW5ldF9u dG9hKHNpbi5zaW5fYWRkciksDQoJICAgIGh0b25zKHNpbi5zaW5fcG9ydCkp Ow0KCWlmIChjb25uZWN0KHNvY2ssIChzdHJ1Y3Qgc29ja2FkZHIgKikmc2lu LCBzaXplb2Yoc2luKSkgPCAwKQ0KCQllcnIoLTEsICJjb25uZWN0KCVzICVk KSIsIGluZXRfbnRvYShzaW4uc2luX2FkZHIpLA0KCQkgICAgaHRvbnMoc2lu LnNpbl9wb3J0KSk7DQoJcHJpbnRmKCJDb25uZWN0ZWRcbiIpOw0KDQoJcmV0 dXJuICgwKTsNCn0NCg== --0-1666198623-1128597308=:84936-- From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 17:16:05 2005 Return-Path: X-Original-To: threads@freebsd.org 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 7D18E16A41F for ; Thu, 6 Oct 2005 17:16:05 +0000 (GMT) (envelope-from Mikhail.Teterin@murex.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F6643D49 for ; Thu, 6 Oct 2005 17:16:02 +0000 (GMT) (envelope-from Mikhail.Teterin@murex.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j96HFvTg032958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Oct 2005 13:16:01 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j96HFpEG092945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Oct 2005 13:15:52 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j96HFjxZ096756; Thu, 6 Oct 2005 13:15:45 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j96HFh2B096755; Thu, 6 Oct 2005 13:15:43 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to Mikhail.Teterin@murex.com using -f From: Mikhail Teterin Organization: Murex North America To: Jason Evans Date: Thu, 6 Oct 2005 13:15:43 -0400 User-Agent: KMail/1.8.2 References: <200510050202.36730@aldan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510061315.43692.Mikhail.Teterin@murex.com> X-Virus-Scanned: ClamAV devel-20050525/1115/Thu Oct 6 01:42:22 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: threads@freebsd.org, jim@corebsd.or.id Subject: Re: Non-threaded app dlopen-ing a thread-using library X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 17:16:05 -0000 четвер 06 жовтень 2005 04:55, Jason Evans Ви написали: > On Oct 4, 2005, at 11:02 PM, Mikhail Teterin wrote: > > Do I need to make the executable itself multi-threaded -- just in case > > it needs to dlopen() a thread-using library, or is there a better way? > > As long as the dlopen()ed library is correctly linked, your app > doesn't need to explicitly link against the library's dependencies. > Dependencies should get pulled in after dlopen() as necessary, on the > fly, as a result of the dlopen()ed library's dependencies. What is the correct way to link a shared object, that uses threads? Using `-pthread' does not seem to change the output of ldd and a non-threaded executable is unable to dlopen() such an object. And for good reason -- the thread-implementation is decided at startup time, not at link-time, is not it? > There's nothing magical about a threaded app, as compared to a non- > threaded app. The first time a pthreads API is called, libpthread > initializes itself. It's fine if this happens as the result of > executing dlopen()ed code; the only issue is making sure that the > library dependencies are set up correctly. So, what happens, when a main executable calls some libc function directly, oblivious to the pthread-wrapper around it, that the dlopen-ed library's code is using? Thanks, -mi From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:11:13 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 9501D16A420; Thu, 6 Oct 2005 22:11:13 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51F0043D46; Thu, 6 Oct 2005 22:11:13 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MBDgE040143; Thu, 6 Oct 2005 22:11:13 GMT (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MBDqw040139; Thu, 6 Oct 2005 22:11:13 GMT (envelope-from deischen) Date: Thu, 6 Oct 2005 22:11:13 GMT From: Daniel Eischen Message-Id: <200510062211.j96MBDqw040139@freefall.freebsd.org> To: freebsd@spatula.net, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Cc: Subject: Re: threads/85112: Resource temporarily unavailable reading from sockets with Java/libpthread/jdbc X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:11:13 -0000 Synopsis: Resource temporarily unavailable reading from sockets with Java/libpthread/jdbc State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Thu Oct 6 22:10:41 GMT 2005 State-Changed-Why: Originator is no longer able to reproduce the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=85112 From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:16:34 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 5874916A420; Thu, 6 Oct 2005 22:16:34 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09EB943D5D; Thu, 6 Oct 2005 22:16:34 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MGXS3040278; Thu, 6 Oct 2005 22:16:33 GMT (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MGXMu040274; Thu, 6 Oct 2005 22:16:33 GMT (envelope-from deischen) Date: Thu, 6 Oct 2005 22:16:33 GMT From: Daniel Eischen Message-Id: <200510062216.j96MGXMu040274@freefall.freebsd.org> To: brlcad@mac.com, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:16:34 -0000 Synopsis: undefined reference to `_thread_dump_info' State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Thu Oct 6 22:15:55 GMT 2005 State-Changed-Why: This interface is an internal interface, not public and is subject to change. http://www.freebsd.org/cgi/query-pr.cgi?pr=86029 From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:20:24 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 28EC016A422 for ; Thu, 6 Oct 2005 22:20:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A364E43D46 for ; Thu, 6 Oct 2005 22:20:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MKNc1040381 for ; Thu, 6 Oct 2005 22:20:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MKMEP040380; Thu, 6 Oct 2005 22:20:22 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 22:20:22 GMT Message-Id: <200510062220.j96MKMEP040380@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Dan Eischen Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:20:24 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: Dan Eischen To: bug-followup@freebsd.org, freebsd@spatula.net Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 06 Oct 2005 18:09:47 -0400 The stack frames shown are not possible. Either the backtrace is not correctly shown, or the stack is corrupt. I would suggest refiling this to -java. From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:20:26 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 B644316A422 for ; Thu, 6 Oct 2005 22:20:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72E2643D48 for ; Thu, 6 Oct 2005 22:20:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MKQvH040388 for ; Thu, 6 Oct 2005 22:20:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MKQ9K040387; Thu, 6 Oct 2005 22:20:26 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 22:20:26 GMT Message-Id: <200510062220.j96MKQ9K040387@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: freebsd@spatula.net Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@spatula.net List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:20:26 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: freebsd@spatula.net To: Dan Eischen Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 15:19:22 -0700 (PDT) What about them is "not possible" exactly? What about ktrace showing a tight loop of kse_release calls followed by RET kse_release 0? Why is it perfectly fine with libc_r? In any case, I had originally reported this to -java, and was sent to -thread from there. On Thu, 6 Oct 2005, Dan Eischen wrote: > The stack frames shown are not possible. Either the backtrace > is not correctly shown, or the stack is corrupt. I would suggest > refiling this to -java. > From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:30:24 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 71EEC16A41F for ; Thu, 6 Oct 2005 22:30:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4154F43D45 for ; Thu, 6 Oct 2005 22:30:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MUOHk040609 for ; Thu, 6 Oct 2005 22:30:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MUOpG040607; Thu, 6 Oct 2005 22:30:24 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 22:30:24 GMT Message-Id: <200510062230.j96MUOpG040607@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:30:24 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: Daniel Eischen To: freebsd@spatula.net Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 18:25:56 -0400 (EDT) On Thu, 6 Oct 2005 freebsd@spatula.net wrote: > What about them is "not possible" exactly? Because [_]nanosleep() does not call pthread_setconcurrency(). And pthread_setconcurrency() does not call pthread_mutexattr_init(). > What about ktrace showing a tight loop of kse_release calls followed by > RET kse_release 0? > > Why is it perfectly fine with libc_r? Libc_r is a totally different beast. You can't necessarily compare apples and oranges. There are much more likely to be race conditions exposed using libpthread than with libc_r. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 22:52:31 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 3190F16A420; Thu, 6 Oct 2005 22:52:31 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6EF43D53; Thu, 6 Oct 2005 22:52:28 +0000 (GMT) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96MqSUA042014; Thu, 6 Oct 2005 22:52:28 GMT (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96MqSjP042010; Thu, 6 Oct 2005 22:52:28 GMT (envelope-from deischen) Date: Thu, 6 Oct 2005 22:52:28 GMT From: Daniel Eischen Message-Id: <200510062252.j96MqSjP042010@freefall.freebsd.org> To: freebsd@spatula.net, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 22:52:31 -0000 Synopsis: libpthread busy loop/hang with Java when handling signals and Runtime.exec State-Changed-From-To: open->suspended State-Changed-By: deischen State-Changed-When: Thu Oct 6 22:51:44 GMT 2005 State-Changed-Why: Not reproducable using -current & jdk1.5. http://www.freebsd.org/cgi/query-pr.cgi?pr=84778 From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 23:00:20 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 885E516A41F for ; Thu, 6 Oct 2005 23:00:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4584643D45 for ; Thu, 6 Oct 2005 23:00:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96N0K0I042250 for ; Thu, 6 Oct 2005 23:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96N0KoB042249; Thu, 6 Oct 2005 23:00:20 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 23:00:20 GMT Message-Id: <200510062300.j96N0KoB042249@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: freebsd@spatula.net Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@spatula.net List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 23:00:20 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: freebsd@spatula.net To: Daniel Eischen Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 15:46:38 -0700 (PDT) select, however, does call nanosleep, and nanosleep does call _nanosleep... but you're right that everything after that looks broken... though I've never seen a stack get smashed like that before. Usually I've seen freakish addresses and "??" for function names, not addresses that look reasonable and function names with symbols that can be actually located. What happens when you gcore a running threaded process? Do the process's threads stop while the core dump is being written? If not, could the stack have changed while the core was being dumped and we're actually seeing bits of stack from multiple running threads (and therefore basically useless information)? Which thread do you see in a core dump if there are multiple threads? On Thu, 6 Oct 2005, Daniel Eischen wrote: > On Thu, 6 Oct 2005 freebsd@spatula.net wrote: > >> What about them is "not possible" exactly? > > Because [_]nanosleep() does not call pthread_setconcurrency(). And > pthread_setconcurrency() does not call pthread_mutexattr_init(). > >> What about ktrace showing a tight loop of kse_release calls followed by >> RET kse_release 0? >> >> Why is it perfectly fine with libc_r? > > Libc_r is a totally different beast. You can't necessarily compare > apples and oranges. There are much more likely to be race conditions > exposed using libpthread than with libc_r. > > -- > DE > From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 23:00:23 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 866AE16A41F for ; Thu, 6 Oct 2005 23:00:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 442DF43D46 for ; Thu, 6 Oct 2005 23:00:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96N0NO2042264 for ; Thu, 6 Oct 2005 23:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96N0NXL042263; Thu, 6 Oct 2005 23:00:23 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 23:00:23 GMT Message-Id: <200510062300.j96N0NXL042263@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 23:00:23 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: Daniel Eischen To: freebsd@spatula.net Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 18:59:14 -0400 (EDT) On Thu, 6 Oct 2005 freebsd@spatula.net wrote: > select, however, does call nanosleep, and nanosleep does call > _nanosleep... but you're right that everything after that looks broken... > though I've never seen a stack get smashed like that before. Usually I've > seen freakish addresses and "??" for function names, not addresses that > look reasonable and function names with symbols that can be actually > located. > > What happens when you gcore a running threaded process? Do the process's > threads stop while the core dump is being written? If not, could the > stack have changed while the core was being dumped and we're actually > seeing bits of stack from multiple running threads (and therefore > basically useless information)? I have no idea what or how gcore works. > Which thread do you see in a core dump if there are multiple threads? I don't know. I've only ever used gdb on running processes. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 23:10:25 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 86A6F16A42D for ; Thu, 6 Oct 2005 23:10:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD71343D48 for ; Thu, 6 Oct 2005 23:10:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96NAOYE046972 for ; Thu, 6 Oct 2005 23:10:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96NAOm0046971; Thu, 6 Oct 2005 23:10:24 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 23:10:24 GMT Message-Id: <200510062310.j96NAOm0046971@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: freebsd@spatula.net Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@spatula.net List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 23:10:25 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: freebsd@spatula.net To: Daniel Eischen Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 16:05:47 -0700 (PDT) Some of us do not have the luxury of running -current and an alpha-quality port on production servers. This is a legitimate bug affecting jdk 1.4 on freebsd-stable, even if it does belong in -java and not -threads. Would it not be better to actually find the cause of the problem and make sure a fix got committed back to the stable branch/port for the majority of FreeBSD Java users? On Thu, 6 Oct 2005, Daniel Eischen wrote: > Synopsis: libpthread busy loop/hang with Java when handling signals and Runtime.exec > > State-Changed-From-To: open->suspended > State-Changed-By: deischen > State-Changed-When: Thu Oct 6 22:51:44 GMT 2005 > State-Changed-Why: > Not reproducable using -current & jdk1.5. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=84778 > From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 23:20:21 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org 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 4BA6416A41F for ; Thu, 6 Oct 2005 23:20:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18C9843D45 for ; Thu, 6 Oct 2005 23:20:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96NKKwW047189 for ; Thu, 6 Oct 2005 23:20:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96NKKcr047188; Thu, 6 Oct 2005 23:20:20 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 23:20:20 GMT Message-Id: <200510062320.j96NKKcr047188@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 23:20:21 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: Daniel Eischen To: freebsd@spatula.net Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 19:11:38 -0400 (EDT) On Thu, 6 Oct 2005 freebsd@spatula.net wrote: > Some of us do not have the luxury of running -current and an alpha-quality > port on production servers. > > This is a legitimate bug affecting jdk 1.4 on freebsd-stable, even if it > does belong in -java and not -threads. > > Would it not be better to actually find the cause of the problem and make > sure a fix got committed back to the stable branch/port for the majority > of FreeBSD Java users? I didn't close the bug (if it is a bug). I only have time and resources to track and run -current. And since it works on -current, and the thread libraries are the same between -current and -stable, I can only assume there is nothing to backport anyways, at least with regard to libpthread (the library). Obviously the kernels vary somewhat. -- DE From owner-freebsd-threads@FreeBSD.ORG Fri Oct 7 16:26:24 2005 Return-Path: X-Original-To: threads@freebsd.org 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 EFB2416A41F; Fri, 7 Oct 2005 16:26:23 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7392143D45; Fri, 7 Oct 2005 16:26:23 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j97GQMdj011952; Fri, 7 Oct 2005 12:26:22 -0400 (EDT) Date: Fri, 7 Oct 2005 12:26:22 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20051006121233.D84936@fledge.watson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 16:26:24 -0000 On Thu, 6 Oct 2005, Robert Watson wrote: > > I was writing test tools yesterday, and was a bit surprised to find that > hitting ctrl-T interrupts connect() for applications linked against > libpthread(). I wrote a simple test tool and found that this is not the > case for any of the other thread libraries (which seems correct to me). > Test tool attached: This isn't a problem with libpthread. If you install a signal handler for SIGINFO in your application with sa_flags = SA_RESTART, it gets interrupted even when just linked with libc. -- DE /*- * Copyright (c) 2005 Robert N. M. Watson * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ #include #include #include #include #include #include #include #include #include #include void sighandler(int sig) { } int main(int argc, char *argv[]) { struct sockaddr_in sin; struct sigaction act; int sock; if (argc != 3) errx(-1, "usage: connect [ip] [port]"); sigfillset(&act.sa_mask); act.sa_flags = SA_RESTART; act.sa_handler = sighandler; sigaction(SIGINFO, &act, NULL); bzero(&sin, sizeof(sin)); sin.sin_len = sizeof(sin); sin.sin_family = AF_INET; sin.sin_addr.s_addr = inet_addr(argv[1]); sin.sin_port = htons(atoi(argv[2])); sock = socket(PF_INET, SOCK_STREAM, 0); if (sock < 0) err(-1, "socket(PF_INET, SOCK_STREAM, 0)"); printf("Connecting to %s:%d\n", inet_ntoa(sin.sin_addr), htons(sin.sin_port)); if (connect(sock, (struct sockaddr *)&sin, sizeof(sin)) < 0) err(-1, "connect(%s %d)", inet_ntoa(sin.sin_addr), htons(sin.sin_port)); printf("Connected\n"); return (0); } From owner-freebsd-threads@FreeBSD.ORG Sat Oct 8 10:16:20 2005 Return-Path: X-Original-To: threads@freebsd.org 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 9E54816A41F; Sat, 8 Oct 2005 10:16:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2479A43D45; Sat, 8 Oct 2005 10:16:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 572A646BA5; Sat, 8 Oct 2005 06:16:17 -0400 (EDT) Date: Sat, 8 Oct 2005 11:16:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20051008105232.B84936@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 10:16:20 -0000 On Fri, 7 Oct 2005, Daniel Eischen wrote: > On Thu, 6 Oct 2005, Robert Watson wrote: > >> I was writing test tools yesterday, and was a bit surprised to find >> that hitting ctrl-T interrupts connect() for applications linked >> against libpthread(). I wrote a simple test tool and found that this >> is not the case for any of the other thread libraries (which seems >> correct to me). Test tool attached: > > This isn't a problem with libpthread. If you install a signal handler > for SIGINFO in your application with sa_flags = SA_RESTART, it gets > interrupted even when just linked with libc. Unlike, say, an I/O operation, the notion of restarting a connect() system call is fairly fraught with peril. Normally, attempts to call connect() on a socket that is already in the process of connecting will return EALREADY, since you don't want to further frob the protocol state machine. A bit of googling suggests that Stephens talks about this in some detail, pointing out that in the EINTR case, the application will really need to select() for the socket becoming writable in order to wait for the connection attempt to finish (or fail). While a bit awkward for the application, it appears these are not uncommon semantics for the system call, and suggest the perils of using blocking I/O with signals are significant. Unfortunately, the problem with this libpthread feature is that, unlike our other thread libraries, it exposes the application to this peril even if the application itself doesn't actively use signals. Is your suggestion that connect() should detect an attempt to connect to the same host and "continue where it left off"? POSIX tells us that EALREADY should be returned if that is attempted: [EALREADY] A connection request is already in progress for the specified socket. I guess in principle we could add a thread flag to indicate that a system call has been restarted, and therefore that the system call should adopt different blocking/waiting smeantics? There are a lot of potential complications though, since you might want to know when it was restarted. In the connect() case it might be straight forward though, converting the current logic to something that short circuits passage into the socket and protocol code: if ((so->so_state & SS_ISCONNECTING) && (td->td_flags & TDF_SARESTARTED)) goto skip_proto: ... error = soconnect(so, sa td); ... skip_proto: if ((so->so_state & SS_NBIO) && (so->so_state & SS_ISCONNECTING)) { error = EINPROGRESS; goto done1; } ... This is only good if we can assume the only interruptible sleep of interest is the msleep() waiting for a transition to SS_ISCONNECTED. If the protocol code itself (called via soconnect()) has interruptible sleeps, then we might need more handling here. I have to admit the whole idea of this is worrying, but then so is the socket life cycle state machine :-). Robert N M Watson > > -- > DE > > /*- > * Copyright (c) 2005 Robert N. M. Watson > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > * > * $FreeBSD$ > */ > > #include > #include > > #include > > #include > > #include > #include > #include > #include > #include > #include > > void > sighandler(int sig) > { > } > > int > main(int argc, char *argv[]) > { > struct sockaddr_in sin; > struct sigaction act; > int sock; > > if (argc != 3) > errx(-1, "usage: connect [ip] [port]"); > > sigfillset(&act.sa_mask); > act.sa_flags = SA_RESTART; > act.sa_handler = sighandler; > sigaction(SIGINFO, &act, NULL); > > bzero(&sin, sizeof(sin)); > sin.sin_len = sizeof(sin); > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = inet_addr(argv[1]); > sin.sin_port = htons(atoi(argv[2])); > > sock = socket(PF_INET, SOCK_STREAM, 0); > if (sock < 0) > err(-1, "socket(PF_INET, SOCK_STREAM, 0)"); > > printf("Connecting to %s:%d\n", inet_ntoa(sin.sin_addr), > htons(sin.sin_port)); > if (connect(sock, (struct sockaddr *)&sin, sizeof(sin)) < 0) > err(-1, "connect(%s %d)", inet_ntoa(sin.sin_addr), > htons(sin.sin_port)); > printf("Connected\n"); > > return (0); > } > > > From owner-freebsd-threads@FreeBSD.ORG Sat Oct 8 15:40:25 2005 Return-Path: X-Original-To: threads@freebsd.org 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 E44A816A41F; Sat, 8 Oct 2005 15:40:25 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FBD543D4C; Sat, 8 Oct 2005 15:40:25 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j98FeNYT028142; Sat, 8 Oct 2005 11:40:23 -0400 (EDT) Date: Sat, 8 Oct 2005 11:40:16 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20051008105232.B84936@fledge.watson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 15:40:26 -0000 On Sat, 8 Oct 2005, Robert Watson wrote: > > On Fri, 7 Oct 2005, Daniel Eischen wrote: > > > On Thu, 6 Oct 2005, Robert Watson wrote: > > > >> I was writing test tools yesterday, and was a bit surprised to find > >> that hitting ctrl-T interrupts connect() for applications linked > >> against libpthread(). I wrote a simple test tool and found that this > >> is not the case for any of the other thread libraries (which seems > >> correct to me). Test tool attached: > > > > This isn't a problem with libpthread. If you install a signal handler > > for SIGINFO in your application with sa_flags = SA_RESTART, it gets > > interrupted even when just linked with libc. > > Unlike, say, an I/O operation, the notion of restarting a connect() system > call is fairly fraught with peril. Normally, attempts to call connect() > on a socket that is already in the process of connecting will return > EALREADY, since you don't want to further frob the protocol state machine. > A bit of googling suggests that Stephens talks about this in some detail, > pointing out that in the EINTR case, the application will really need to > select() for the socket becoming writable in order to wait for the > connection attempt to finish (or fail). While a bit awkward for the > application, it appears these are not uncommon semantics for the system > call, and suggest the perils of using blocking I/O with signals are > significant. Unfortunately, the problem with this libpthread feature is > that, unlike our other thread libraries, it exposes the application to > this peril even if the application itself doesn't actively use signals. > > Is your suggestion that connect() should detect an attempt to connect to > the same host and "continue where it left off"? POSIX tells us that > EALREADY should be returned if that is attempted: No, SA_RESTART should do what it says it should do. System calls should be restartable. The man page for sigaction() says that it is only open(), read(), write(), sendto(), recvfrom(), sendmsg(), and recvmsg() that are restartable. I don't know why connect() should be any different. In this case there is only one thread that is attempting to [re]connect(), so I don't see why you'd think EALREADY should be returned. A thread gets interrupted to run a signal handler, it leaves the kernel so there is no thread attempting to connect(). If the handler returns (it doesn't have to), then why can't it go back to connecting again? There is no timeout on connect() (you'd have to select() or poll()), and the application can choose SA_RESTART or not, so allowing connect() to be restartable shouldn't break anything. It only works with libc_r because libc_r wraps all these calls (including connect()) with poll(). Obviously we're not going to do that with libpthread. You're only seeing it with SIGINFO because we use SIGINFO as a debugging signal for libpthread (to dump thread state). libpthread doesn't install any other signal handlers unless the application does. We could use a different signal or not use SIGINFO at all. -- DE From owner-freebsd-threads@FreeBSD.ORG Sat Oct 8 15:58:07 2005 Return-Path: X-Original-To: threads@freebsd.org 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 86DB216A41F; Sat, 8 Oct 2005 15:58:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D58243D48; Sat, 8 Oct 2005 15:58:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (unknown [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 59DC646B40; Sat, 8 Oct 2005 11:58:06 -0400 (EDT) Date: Sat, 8 Oct 2005 16:58:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20051008165620.T17032@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 15:58:07 -0000 On Sat, 8 Oct 2005, Daniel Eischen wrote: > It only works with libc_r because libc_r wraps all these calls > (including connect()) with poll(). Obviously we're not going to do that > with libpthread. You're only seeing it with SIGINFO because we use > SIGINFO as a debugging signal for libpthread (to dump thread state). > libpthread doesn't install any other signal handlers unless the > application does. We could use a different signal or not use SIGINFO at > all. Ah, so this is why my /tmp is full of garbage :-): -rw-r--r-- 1 robert wheel 1823 Oct 5 20:32 /tmp/pthread.dump.49376.0 -rw-r--r-- 1 robert wheel 1822 Oct 5 20:32 /tmp/pthread.dump.49376.1 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.0 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.1 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.10 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.11 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.12 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.13 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.14 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.15 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.16 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.17 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.2 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.3 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.4 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.5 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.6 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.7 -rw-r--r-- 1 robert wheel 1861 Oct 5 20:32 /tmp/pthread.dump.49385.8 -rw-r--r-- 1 robert wheel 1860 Oct 5 20:32 /tmp/pthread.dump.49385.9 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.0 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.1 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.10 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.11 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.12 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.13 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.2 -rw-r--r-- 1 robert wheel 1857 Oct 5 21:16 /tmp/pthread.dump.49954.3 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.4 -rw-r--r-- 1 robert wheel 1857 Oct 5 21:16 /tmp/pthread.dump.49954.5 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.6 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.7 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.8 -rw-r--r-- 1 robert wheel 1856 Oct 5 21:16 /tmp/pthread.dump.49954.9 -rw-r--r-- 1 robert wheel 338 Oct 5 21:16 /tmp/pthread.dump.49956.0 -rw-r--r-- 1 robert wheel 338 Oct 6 12:12 /tmp/pthread.dump.54401.0 -rw-r--r-- 1 robert wheel 338 Oct 6 12:18 /tmp/pthread.dump.54419.0 -rw-r--r-- 1 robert wheel 1016 Oct 6 12:11 /tmp/uthread.dump.54363.0 -rw-r--r-- 1 robert wheel 1016 Oct 6 12:12 /tmp/uthread.dump.54400.0 -rw-r--r-- 1 robert wheel 1016 Oct 6 12:12 /tmp/uthread.dump.54402.0 As you might guess, I like to hit ^T to find out what an application is doing. Regardless of whether the application has its own SIGINFO handler or not. libpthread should not implement SIGINFO unless some or another special circumstances apply -- environmental variable, or compile option, or such. Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Sat Oct 8 23:39:51 2005 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BA5CD16A41F; Sat, 8 Oct 2005 23:39:50 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <434858D0.1080308@freebsd.org> Date: Sun, 09 Oct 2005 07:40:00 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20051008105232.B84936@fledge.watson.org> In-Reply-To: <20051008105232.B84936@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 23:39:51 -0000 Robert Watson wrote: > > > On Fri, 7 Oct 2005, Daniel Eischen wrote: > >> On Thu, 6 Oct 2005, Robert Watson wrote: >> >>> I was writing test tools yesterday, and was a bit surprised to find >>> that hitting ctrl-T interrupts connect() for applications linked >>> against libpthread(). I wrote a simple test tool and found that >>> this is not the case for any of the other thread libraries (which >>> seems correct to me). Test tool attached: >> >> >> This isn't a problem with libpthread. If you install a signal >> handler for SIGINFO in your application with sa_flags = SA_RESTART, >> it gets interrupted even when just linked with libc. > > > Unlike, say, an I/O operation, the notion of restarting a connect() > system call is fairly fraught with peril. Normally, attempts to call > connect() on a socket that is already in the process of connecting > will return EALREADY, since you don't want to further frob the > protocol state machine. A bit of googling suggests that Stephens talks > about this in some detail, pointing out that in the EINTR case, the > application will really need to select() for the socket becoming > writable in order to wait for the connection attempt to finish (or > fail). While a bit awkward for the application, it appears these are > not uncommon semantics for the system call, and suggest the perils of > using blocking I/O with signals are significant. Unfortunately, the > problem with this libpthread feature is that, unlike our other thread > libraries, it exposes the application to this peril even if the > application itself doesn't actively use signals. > > Is your suggestion that connect() should detect an attempt to connect > to the same host and "continue where it left off"? POSIX tells us > that EALREADY should be returned if that is attempted: > > [EALREADY] > A connection request is already in progress for the specified socket. > Unfortunately, it is not stable to use errno, problem is many programmers do not preserve errno in signal handler, so after the signal handler did a failure syscall, the errno must not be EALREADY, although I know libpthread has code to protect errno in signal handler, but not other thread libraries, this is also not a portable feature. :-) David Xu