From owner-freebsd-threads@FreeBSD.ORG Mon Jul 18 05:00:59 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 4F50716A41C for ; Mon, 18 Jul 2005 05:00:59 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0FD143D49 for ; Mon, 18 Jul 2005 05:00:58 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id 4so792174nzn for ; Sun, 17 Jul 2005 22:00:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=NIwo1xL6JnjRfX/OCOWPV+uLgNZ//4AtJsOyQ1z71gfKAmoOM0mpWNBhd0DRK7SoIpdjIldilyHiHAQE59rEE1t90/tEssQWfkduqvfnXjBH+E2g9c7Z6VisvzHxbbm6ONJp0xuWxUMuuBnhNwE1IqWv4FmVmYAYR+9vUJDHnbw= Received: by 10.36.220.55 with SMTP id s55mr3674249nzg; Sun, 17 Jul 2005 22:00:57 -0700 (PDT) Received: from ?192.168.15.103? ([68.190.230.198]) by mx.gmail.com with ESMTP id c12sm1870080nzc.2005.07.17.22.00.55; Sun, 17 Jul 2005 22:00:57 -0700 (PDT) From: Pascal Hofstee To: freebsd-threads@freebsd.org In-Reply-To: <1121453983.672.15.camel@synergy.charterpipeline.net.lan> References: <1121453983.672.15.camel@synergy.charterpipeline.net.lan> Content-Type: text/plain Date: Sun, 17 Jul 2005 22:00:53 -0700 Message-Id: <1121662853.701.10.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.5.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: David Ayers Subject: [PATCH] Re: GNUstep, libobjc and threading 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, 18 Jul 2005 05:00:59 -0000 On Fri, 2005-07-15 at 12:00 -0700, Pascal Hofstee wrote: > Is the above analysis enough information to hopefully fix this problem > with FreeBSD's threading libraries ... and would properly gaurding the > mentioned pthread_key_create function with a similar _thread_initial > check be sufficient ? Well .. i decided to give it a shot and tried to patch up libpthread myself with the information provided by David Ayers. And i have so far seen no ill-effects of my changes, but at least these GNUstep problems now are resolved. (GNUstep and FreeBSD/amd64 still don't exactly like eachother but that's because of at least a number of potential 64-bit issues which we're currently trying to resolve within GNUstep itself.) Below patches fix the problem as described in the analysis: --- lib/libpthread/thread/thr_spec.c.orig Sat Jul 16 19:28:31 2005 +++ lib/libpthread/thread/thr_spec.c Sat Jul 16 19:28:41 2005 @@ -50,8 +50,13 @@ int _pthread_key_create(pthread_key_t *key, void (*destructor) (void *)) { - struct pthread *curthread = _get_curthread(); + struct pthread *curthread; int i; + + if (_thr_initial == NULL) + _libpthread_init(NULL); + + curthread = _get_curthread(); /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); --- lib/libthr/thread/thr_spec.c.orig Sat Jul 16 19:29:04 2005 +++ lib/libthr/thread/thr_spec.c Sat Jul 16 19:29:14 2005 @@ -52,8 +52,13 @@ int _pthread_key_create(pthread_key_t *key, void (*destructor) (void *)) { - struct pthread *curthread = _get_curthread(); + struct pthread *curthread; int i; + + if (_thr_initial == NULL) + _libpthread_init(NULL); + + curthread = _get_curthread(); /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); I just realized it may be possible to do the whole _thr_initial dance inside the actual _get_curthread() function ... if that turns out to be the case .. perhaps that location would be more suitable than this 'stopgap'. With kind regards, Pascal Hofstee From owner-freebsd-threads@FreeBSD.ORG Mon Jul 18 05:15:01 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 6D71C16A41C for ; Mon, 18 Jul 2005 05:15:01 +0000 (GMT) (envelope-from d.ayers@inode.at) Received: from mail.turbocat.net (mail.turbocat.net [213.133.116.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id D828943D48 for ; Mon, 18 Jul 2005 05:15:00 +0000 (GMT) (envelope-from d.ayers@inode.at) Received: by mail.turbocat.net (Postfix, from userid 1002) id C086D422EC43; Mon, 18 Jul 2005 07:14:57 +0200 (CEST) Received: from [10.0.0.13] (83-65-214-98.work.xdsl-line.inode.at [83.65.214.98]) by mail.turbocat.net (Postfix) with ESMTP id AD5F9422EC2A; Mon, 18 Jul 2005 07:14:56 +0200 (CEST) Message-ID: <42DB3A6B.90309@inode.at> Date: Mon, 18 Jul 2005 07:13:15 +0200 From: David Ayers User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 To: Pascal Hofstee References: <1121453983.672.15.camel@synergy.charterpipeline.net.lan> <1121662853.701.10.camel@synergy.charterpipeline.net.lan> In-Reply-To: <1121662853.701.10.camel@synergy.charterpipeline.net.lan> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: [PATCH] Re: GNUstep, libobjc and threading 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, 18 Jul 2005 05:15:01 -0000 Pascal Hofstee schrieb: > On Fri, 2005-07-15 at 12:00 -0700, Pascal Hofstee wrote: > > I just realized it may be possible to do the whole _thr_initial dance > inside the actual _get_curthread() function ... if that turns out to be > the case .. perhaps that location would be more suitable than this > 'stopgap'. FWIW, personally I think your patch is the correct approach. Putting the initialization in _get_curthread() may be a 'stopgap' but it may hit the performance unduly. In the case of the API functions, I believe the correctness issue trumps performance issues. Cheers, David Ayers From owner-freebsd-threads@FreeBSD.ORG Mon Jul 18 11:02:31 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 4103516A425 for ; Mon, 18 Jul 2005 11:02:31 +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 ECB1943D49 for ; Mon, 18 Jul 2005 11:02:30 +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 j6IB2Ubq098360 for ; Mon, 18 Jul 2005 11:02:30 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6IB2UUt098354 for freebsd-threads@freebsd.org; Mon, 18 Jul 2005 11:02:30 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 18 Jul 2005 11:02:30 GMT Message-Id: <200507181102.j6IB2UUt098354@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, 18 Jul 2005 11:02:31 -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 o [2003/05/08] threads/51949threads thread in accept cannot be cancelled 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/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro 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 26 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 13 problems total.