From owner-freebsd-threads@FreeBSD.ORG Sat May 31 20:48:19 2003 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 E3EFB37B401 for ; Sat, 31 May 2003 20:48:18 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1892943F93 for ; Sat, 31 May 2003 20:48:18 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.45.55]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030601034817.OXXJ20810.pop015.verizon.net@kokeb.ambesa.net>; Sat, 31 May 2003 22:48:17 -0500 Date: Sat, 31 May 2003 23:48:15 -0400 From: Mike Makonnen To: Marcel Moolenaar In-Reply-To: <20030531072259.GA2408@athlon.pn.xcllnt.net> References: <20030531072259.GA2408@athlon.pn.xcllnt.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.45.55] at Sat, 31 May 2003 22:48:16 -0500 Message-Id: <20030601034817.OXXJ20810.pop015.verizon.net@kokeb.ambesa.net> cc: threads@freebsd.org Subject: Re: libthr: thr_create(2): no kernel stack? 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, 01 Jun 2003 03:48:19 -0000 On Sat, 31 May 2003 00:22:59 -0700 Marcel Moolenaar wrote: > Gang, > > I'm porting libthr to ia64 and reached a point where I can actually > do initial testing. I immediately hit upon a snafu in thr_create(2). > The second bcopy (ie sys/kern/kern_thr.c:159) is panicing because > the new thread (td0) does not have a frame (ie td_frame == NULL). > Creating a frame is obviously the thing to do, but there's no kernel > stack created for the new thread AFAICT. Without kernel thread. > cpu_set_upcall() will also fail if we ever reach that point. > > Am I missing something here? I just took a look at this and it _did_ look funny, but it seems to work on i386 so I did a little more digging and it seems that the stack frame is allocated in the uma thread initialization routine thread_init(), which calls cpu_thread_setup(). This is currently undefined for ia64: ia64/ia64/vm_machdep.c: line 110 Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Sat May 31 22:27:42 2003 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 E003B37B401 for ; Sat, 31 May 2003 22:27:42 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38B1C43FBF for ; Sat, 31 May 2003 22:27:42 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h515ReNc025254; Sun, 1 Jun 2003 01:27:41 -0400 (EDT) Date: Sun, 1 Jun 2003 01:27:40 -0400 (EDT) From: Daniel Eischen To: Martin Blapp In-Reply-To: <20030531104908.O94836@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: konsole does still now work in libthr, libkse 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, 01 Jun 2003 05:27:43 -0000 On Sat, 31 May 2003, Martin Blapp wrote: > > Hi all, > > After a make world and new kernel with newest cvs, > konsole does > > with libkse: opens a win, and closes it immediatly again. > with libthr: crashes instantly (but only the first one) > with libc_r: works just fine > > Note. To test it you _must_ restart your X, just changeing > libmap does not help at all. Weird. From what I can tell, it's trying to chown on /dev/ttypN and failing (permission error). When this happens, I think it aborts itself. If I run konsole a few times in a row, it eventually works and then I can't get it to fail. If I compile libkse with -g, it only fails once and then works. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat May 31 23:13:45 2003 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 0974837B404 for ; Sat, 31 May 2003 23:13:45 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BDB43F85 for ; Sat, 31 May 2003 23:13:43 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h516Dhwk091145; Sat, 31 May 2003 23:13:43 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h516Dgqu001124; Sat, 31 May 2003 23:13:42 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h516Dgq7001123; Sat, 31 May 2003 23:13:42 -0700 (PDT) Date: Sat, 31 May 2003 23:13:42 -0700 From: Marcel Moolenaar To: Mike Makonnen Message-ID: <20030601061342.GA1075@dhcp01.pn.xcllnt.net> References: <20030531072259.GA2408@athlon.pn.xcllnt.net> <20030601034817.OXXJ20810.pop015.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030601034817.OXXJ20810.pop015.verizon.net@kokeb.ambesa.net> User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: libthr: thr_create(2): no kernel stack? 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, 01 Jun 2003 06:13:46 -0000 On Sat, May 31, 2003 at 11:48:15PM -0400, Mike Makonnen wrote: > On Sat, 31 May 2003 00:22:59 -0700 > > > > I'm porting libthr to ia64 and reached a point where I can actually > > do initial testing. I immediately hit upon a snafu in thr_create(2). > > The second bcopy (ie sys/kern/kern_thr.c:159) is panicing because > > the new thread (td0) does not have a frame (ie td_frame == NULL). > > Creating a frame is obviously the thing to do, but there's no kernel > > stack created for the new thread AFAICT. Without kernel thread. > > cpu_set_upcall() will also fail if we ever reach that point. > > > > Am I missing something here? > > I just took a look at this and it _did_ look funny, but it seems to work on i386 > so I did a little more digging and it seems that the stack frame is allocated in > the uma thread initialization routine thread_init(), which calls > cpu_thread_setup(). > This is currently undefined for ia64: ia64/ia64/vm_machdep.c: line 110 Ah, ok. Thanks. I got distracted by an ia64 specific hack in kern_thread.c. I just committed the removal of that hack. I too was in the process of figuring out why it worked on i386. You beat me to it ;-) Thanks. I'll commit an implementation shorty, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 00:40:50 2003 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 F2C9B37B404 for ; Sun, 1 Jun 2003 00:40:49 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 641B343F85 for ; Sun, 1 Jun 2003 00:40:47 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h617ehwu010958; Sun, 1 Jun 2003 10:40:43 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h517dj1r005724; Sun, 1 Jun 2003 10:39:45 +0300 (EEST) (envelope-from netch) Date: Sun, 1 Jun 2003 10:39:45 +0300 From: Valentin Nechayev To: "Matthew D. Fuller" Message-ID: <20030601073945.GA5594@iv.nn.kiev.ua> References: <20030531024932.GP61246@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030531024932.GP61246@over-yonder.net> X-42: On Organization: Dark side of coredump cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Transition plans: libkse->libpthread 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, 01 Jun 2003 07:40:50 -0000 Fri, May 30, 2003 at 21:49:32, fullermd (Matthew D. Fuller) wrote about "Re: Transition plans: libkse->libpthread": >> Sometime shortly after 5.1 release, we'll (hopefully) be >> installing libpthread as "libpthread" instead of "libkse" >> by default. MDF> From my comfortable position here in the peanut gallery, I've been MDF> thinking about this. Now that we have libthr around (presumably for a MDF> long time), mightn't it be a good idea to keep libkse and libkse, libthr MDF> and libthr, and maybe even libc_r as libc_r, and have libpthread be a MDF> {sym,hard}link to one of the above? Since we're ending up with multiple MDF> libraries implementing the pthreads API, with the presumption that MDF> they're at least nominally interchangeable, might we not want to make MDF> that switchability explicit? I joined to this initially. But: 1. System-wide changing of, e.g., libkse to libthr in all applications, can be set up in libmap.conf. If system-wide libmap.conf is applicable by default to all binaries, including sugid ones, this will work. 2. Linker writes library specifications to binaries not with library name only, but with major number also. With libpthread as customized symlink, version bumps in all three libraries must be simultaneous and major numbers must be identical. With one default library, if libmap allows, any libpthread version can be mapped to any libthr or libc_r version. This is preferrable. So, I support installing libkse as libpthread using copy or (preferred) hard link. -netch- From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 00:43:26 2003 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 2FACB37B401 for ; Sun, 1 Jun 2003 00:43:26 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42A5143F85 for ; Sun, 1 Jun 2003 00:43:24 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h617hMXM010986; Sun, 1 Jun 2003 10:43:22 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h517h7Q9005984; Sun, 1 Jun 2003 10:43:07 +0300 (EEST) (envelope-from netch) Date: Sun, 1 Jun 2003 10:43:07 +0300 From: Valentin Nechayev To: Daniel Eischen Message-ID: <20030601074307.GB5594@iv.nn.kiev.ua> References: <20030531024932.GP61246@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On Organization: Dark side of coredump cc: threads@freebsd.org Subject: Re: Transition plans: libkse->libpthread 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, 01 Jun 2003 07:43:26 -0000 Sat, May 31, 2003 at 01:39:59, eischen (Daniel Eischen) wrote about "Re: Transition plans: libkse->libpthread": DE> No :-) In my mind, the KSE threads library was always supposed DE> to be libpthread (note the 'p' for POSIX). libthr is not able DE> to be fully POSIX compat because the kernel schedules threads DE> and the kernel doesn't conform to POSIX scheduling. I know I'm DE> in the minority, but I think libthr interfaces should "thr_foo()" DE> (similar to Solaris libthread), not "pthread_foo()". But that DE> prevents it from being easily used as a drop-in replacement DE> for libc_r. Can you link one app both with libthr and libpthread? I think no ;) You can add thr_* as alias or for any function specific to libthr, but there are no direct reason to prohibit libthr having pthread interface. DE> We have a mechanism for selecting the threads library that DE> the ports system should be using (PTHREAD_LIBS); it's just DE> not always being obeyed by some ports. How about customizing -pthread or -lpthread flags on GCC level? (Untested idea) -netch- From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 03:29:20 2003 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 D1D4F37B401 for ; Sun, 1 Jun 2003 03:29:20 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BB7C43F85 for ; Sun, 1 Jun 2003 03:27:59 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h51ARuEU006844 for ; Sun, 1 Jun 2003 12:27:57 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 1 Jun 2003 12:27:56 +0200 (CEST) From: Martin Blapp To: freebsd-threads@freebsd.org Message-ID: <20030601122636.V94836@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Unable to compile jdk1.4.1 with libkse 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, 01 Jun 2003 10:29:21 -0000 Hi all, I'd like that you try to compile jdk1.4.1 from ports. The port will fail to finish with libkse. You'll get several Sig11 and aborts during compile. With libc_r it works. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 04:50:44 2003 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 6437037B401; Sun, 1 Jun 2003 04:50:43 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB7D43FEA; Sun, 1 Jun 2003 04:48:01 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h51Blxk8003819; Sun, 1 Jun 2003 14:48:01 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3ED9E7EF.3080100@he.iki.fi> Date: Sun, 01 Jun 2003 14:47:59 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: halt thread / mmap chatter 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, 01 Jun 2003 11:50:45 -0000 Got the chatter below on a box which had some libkse and some mmap activity when it got shutdown. Built from morning of 30th May sources. Pete May 30 08:56:08 kompak halt: hallted by root ock order reversal 1st 0xc3335aa8 sigacts (sigacts) @ kern/subr_trap.c:248 2nd 0xc3347d88 process lock (process lock) @ kern/kern_thread.c:1453 Stack backtrace: backtrace(c0394b65,c3347d88,c039176d,c039176d,c0392acc) at backtrace+0x17 witness_lock(c3347d88,8,c0392acc,5ad,0) at witness_lock+0x697 _mtx_lock_flags(c3347d88,0,c0392ac3,5ad,c3347d20,c3347d88,4000,0,0,0) at _mtx_lock_flags+0xb1 thread_signal_add(c3327390,f,c0392177,85e,80e1310) at thread_signal_add+0xe1 postsig(f,0,c0394609,f8,20800) at postsig+0x356 ast(d2f53d48) at ast+0x46f doreti_ast() at doreti_ast+0x17 Mem1: promiscuous mode disabled lock order reversal 1st 0xc3351818 vm object (vm object) @ vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325 Stack backtrace: backtrace(c0394b65,c082f110,c03a2bf2,c03a2bf2,c03a2a96) at backtrace+0x17 witness_lock(c082f110,8,c03a2a96,145,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c03a2a8d,145,3) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c03a2a8d,145,d2f53a40,c0211354) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,d2f53aac,c030ea00) at kmem_malloc+0x66 page_alloc(c083a240,1000,d2f53a9f,101,c03c48cc) at page_alloc+0x27 slab_zalloc(c083a240,101,c03a442f,66f,c083a924) at slab_zalloc+0x150 uma_zone_slab(c083a240,101,c03a4426,66f,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a240,0,101,6ef,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a900,c3368000,0,d2f53b54,c02f68d8) at uma_zfree_arg+0x2cb dev_pager_putfake(c3368000,0,c03a22ce,bc,c3351818) at dev_pager_putfake+0x3a dev_pager_dealloc(c3351818,1,c03a4335,10b,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c3351818,0,c03a3523,25e,c03f8848) at vm_pager_deallocate+0x3d vm_object_terminate(c3351818,0,c03a3523,200,c28b5834) at vm_object_terminate+0x1f4 vm_object_deallocate(c3351818,c28b5834,c3351818,c28b5834,d2f53c24) at vm_object_deallocate+0x20f vm_map_entry_delete(c28cbd00,c28b5834,c03a2c60,86e,c03904ed) at vm_map_entry_delete+0x3b vm_map_delete(c28cbd00,0,bfc00000,c28cbd00,c2677280) at vm_map_delete+0x453 vm_map_remove(c28cbd00,0,bfc00000,111,c0392177) at vm_map_remove+0x58 exit1(c3327390,9,c0392177,8d8,1) at exit1+0x626 sigexit(c3327390,9,c0392177,865,0) at sigexit+0x1a7 postsig(9,0,c0394609,f8,20800) at postsig+0x164 ast(d2f53d48) at ast+0x46f doreti_ast() at doreti_ast+0x17 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 10 10 6 5 5 done Uptime: 2h40m11s The operating system has halted. Please press any key to reboot. From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 06:29:42 2003 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 6551D37B401 for ; Sun, 1 Jun 2003 06:29:42 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C1F443FDD for ; Sun, 1 Jun 2003 06:28:21 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h51DSJNc020749; Sun, 1 Jun 2003 09:28:19 -0400 (EDT) Date: Sun, 1 Jun 2003 09:28:18 -0400 (EDT) From: Daniel Eischen To: Valentin Nechayev In-Reply-To: <20030601074307.GB5594@iv.nn.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Transition plans: libkse->libpthread 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, 01 Jun 2003 13:29:42 -0000 On Sun, 1 Jun 2003, Valentin Nechayev wrote: > Sat, May 31, 2003 at 01:39:59, eischen (Daniel Eischen) wrote about "Re: Transition plans: libkse->libpthread": > > DE> No :-) In my mind, the KSE threads library was always supposed > DE> to be libpthread (note the 'p' for POSIX). libthr is not able > DE> to be fully POSIX compat because the kernel schedules threads > DE> and the kernel doesn't conform to POSIX scheduling. I know I'm > DE> in the minority, but I think libthr interfaces should "thr_foo()" > DE> (similar to Solaris libthread), not "pthread_foo()". But that > DE> prevents it from being easily used as a drop-in replacement > DE> for libc_r. > > Can you link one app both with libthr and libpthread? I think no ;) No, that's not what I'm saying at all. > You can add thr_* as alias or for any function specific to libthr, > but there are no direct reason to prohibit libthr having pthread interface. > > DE> We have a mechanism for selecting the threads library that > DE> the ports system should be using (PTHREAD_LIBS); it's just > DE> not always being obeyed by some ports. > > How about customizing -pthread or -lpthread flags on GCC level? > (Untested idea) Why is there confusion? The linker already supports this in -current. We can choose to link to any threads library just by specifying -lc_r, -lthr, or -lpthread. All you need to do is set PTHREAD_LIBS to whichever one you choose. If you want to build mozilla with libthr, set PTHREAD_LIBS accordingly. In another window, if you want to build KDE with libpthread, set PTHREAD_LIBS to -lpthread. Mozilla will be built linked to libthr.so.1, and KDE linked to libpthread.so.1. You can run them both at the same time without any problem and they will both be using different thread libraries. If you find one application works better with one library, and another application works better with a different threads library, this lets you pick and choose. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 06:39:40 2003 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 AAE7B37B401 for ; Sun, 1 Jun 2003 06:39:40 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C464143FF9 for ; Sun, 1 Jun 2003 06:38:19 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h51DcINc021881; Sun, 1 Jun 2003 09:38:19 -0400 (EDT) Date: Sun, 1 Jun 2003 09:38:18 -0400 (EDT) From: Daniel Eischen To: Martin Blapp In-Reply-To: <20030601122636.V94836@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Unable to compile jdk1.4.1 with libkse 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, 01 Jun 2003 13:39:41 -0000 On Sun, 1 Jun 2003, Martin Blapp wrote: > > Hi all, > > I'd like that you try to compile jdk1.4.1 from > ports. The port will fail to finish with libkse. > You'll get several Sig11 and aborts during compile. > > With libc_r it works. I'll try sometime later this week if I get the chance. Got a log? Are you building with libkse copied over libc_r? Usually, I leave libc_r alone when building stuff, and then copy (or libmap) libkse afterwards. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 07:00:42 2003 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 CCA8F37B401; Sun, 1 Jun 2003 07:00:42 -0700 (PDT) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B18743FE3; Sun, 1 Jun 2003 06:58:01 -0700 (PDT) (envelope-from kabaev@mail.ru) Received: from mx8.mail.ru (mx8.mail.ru [194.67.23.28]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 46663E2B1F; Sun, 1 Jun 2003 17:58:00 +0400 (MSD) Received: from [151.203.5.191] (port=51012 helo=kan.dnsalias.net) by mx8.mail.ru with esmtp id 19MTKy-0004tf-00; Sun, 01 Jun 2003 17:57:28 +0400 Received: from kan.dnsalias.net (ak03@localhost [127.0.0.1]) by kan.dnsalias.net (8.12.9/8.12.9) with ESMTP id h51DvQ54005946; Sun, 1 Jun 2003 09:57:26 -0400 (EDT) (envelope-from kan@kan.dnsalias.net) Received: (from kan@localhost) by kan.dnsalias.net (8.12.9/8.12.9/Submit) id h51DvQhK005945; Sun, 1 Jun 2003 09:57:26 -0400 (EDT) Date: Sun, 1 Jun 2003 09:57:25 -0400 From: Alexander Kabaev To: Martin Blapp , freebsd-threads@freebsd.org Message-Id: <20030601095725.08bcc523.kabaev@mail.ru> In-Reply-To: <20030601112540.V94836@cvs.imp.ch> References: <20030601112540.V94836@cvs.imp.ch> X-Mailer: Sylpheed version 0.9.0claws2 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: Not detected cc: freebsd-current@freebsd.org Subject: Re: vm-related panic with 5.1RC1 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, 01 Jun 2003 14:00:45 -0000 On Sun, 1 Jun 2003 11:26:12 +0200 (CEST) Martin Blapp wrote: > > Hi all, > > I just got this panic during compile of openoffice > > Fatal trap 12 while in kernel mode > fault virtual address = 0x68 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0271f4d > stack pointer = 0x10:0xe6e51ab0 > frame pointer = 0x10:0xe6e51ae0 > code segement = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32, gran 1 > processor flags = interrupt enabled, resume, IOPL =1 > current process = 22362 > kernel: type 12 trap, code=0 > Stopped at _mtx_lock_sleep+0x16d: movl 0x68(%ecx),%edx > db> trace > _mtx_lock_sleep(c082f0b0,0,0,0,c0678415) at _mtx_lock_sleep+0x16d > vm_map_delete(c082f000, d0d0d000, d0d11000, e6effda0, c78d5720) at > vm_map_delete+0x383) vm_map_remove(c082f000, d0d0d000, d0d11000, > e6e51b9c, c03b247f) at vm_map_remove+0x58) kmem_free(c082f000, > d0d0d000, 3000, 0, 80) at kmem_free+0x32 cpu_thread_clean(c78d54c0, > e6e51bb4,c78d54c0, c78d54c0, e6e51be4) at cpu_thread_clean+0x7f > thread_free(c78d54c0, e6e51bd0, c0275839, c67a3000, c6abf030) at > thread_free+0x14 thread_reap(c78d55f0) at thread_reap+0x16c > thread_wait(c656b000, ffffffff, 0, c03feb34,0) at thread_wait+0x55 > wait1(c6569980, e6e51d10, 0, e6e51d40, c03b0dfa) at wait1+0x738 > wait5(c6569980, e6e51d10, 10, c6569980, 4) at wait4+0x20 > syscall(2f, 2f, 2f, bfbff074, 325) at syscall+0x2aa > Xint0x80_syscall() at Xint0x80_syscall()+0x1d > --- syscall (7, FreeBSD ELF32, wait4) eip = 0x807b28b, esp = > 0xbfbfefbc, ebp = 0xbfbfefd8) > > Unfortunatly my partition was too small, so I could not get a dump. > I've adjusted this now and the next time it panics I'll have one > ready. > > Martin This is exactly the panic I am seeing on my dual-processor box. My current suspicion is that it somehow relates to the same pcb_ext being freed twice. I do not need OpenOffice to trigger the bug, on SMP configuration it happens all the time. From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 10:10:57 2003 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 9D93537B401 for ; Sun, 1 Jun 2003 10:10:57 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37EB743F3F for ; Sun, 1 Jun 2003 10:10:56 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h51HArEU048120; Sun, 1 Jun 2003 19:10:53 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 1 Jun 2003 19:10:53 +0200 (CEST) From: Martin Blapp To: Daniel Eischen In-Reply-To: Message-ID: <20030601190900.H94836@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Unable to compile jdk1.4.1 with libkse 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, 01 Jun 2003 17:10:57 -0000 Hi, > I'll try sometime later this week if I get the chance. > Got a log? I can put one available of course ... I got the sig11 always at the same place. Then I've switched to libc_r and it worked. > Are you building with libkse copied over libc_r? Usually, I > leave libc_r alone when building stuff, and then copy (or libmap) > libkse afterwards. No, I just use libmap and have just libkse in there so it replaces all libc_r calls. Martin From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 12:16:37 2003 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 993D237B401 for ; Sun, 1 Jun 2003 12:16:37 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E283343F93 for ; Sun, 1 Jun 2003 12:16:36 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h51JGZNc003503; Sun, 1 Jun 2003 15:16:36 -0400 (EDT) Date: Sun, 1 Jun 2003 15:16:35 -0400 (EDT) From: Daniel Eischen To: Martin Blapp In-Reply-To: <20030601190900.H94836@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Unable to compile jdk1.4.1 with libkse 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, 01 Jun 2003 19:16:37 -0000 On Sun, 1 Jun 2003, Martin Blapp wrote: > > Hi, > > > I'll try sometime later this week if I get the chance. > > Got a log? > > I can put one available of course ... I got the sig11 always > at the same place. Then I've switched to libc_r and it worked. Ok, can you make it available? If it's large, can you put it up somewhere for me to download? Thanks. > > > Are you building with libkse copied over libc_r? Usually, I > > leave libc_r alone when building stuff, and then copy (or libmap) > > libkse afterwards. > > No, I just use libmap and have just libkse in there so it replaces > all libc_r calls. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 12:21:22 2003 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 2977037B401 for ; Sun, 1 Jun 2003 12:21:22 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 823D843F75 for ; Sun, 1 Jun 2003 12:21:21 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h51JLKNc004148 for ; Sun, 1 Jun 2003 15:21:20 -0400 (EDT) Date: Sun, 1 Jun 2003 15:21:20 -0400 (EDT) From: Daniel Eischen To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Away for a few days 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, 01 Jun 2003 19:21:22 -0000 I'll be away on business starting today through Thursday (6/5). I may have limited connectivity, but don't expect any responses until I get back. Have a good week. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Jun 1 15:10:52 2003 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 D4E6637B401 for ; Sun, 1 Jun 2003 15:10:52 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E215143F75 for ; Sun, 1 Jun 2003 15:10:51 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h51MApwk096096 for ; Sun, 1 Jun 2003 15:10:51 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h51MAp2Y001042 for ; Sun, 1 Jun 2003 15:10:51 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h51MAptR001041 for threads@FreeBSD.org; Sun, 1 Jun 2003 15:10:51 -0700 (PDT) Date: Sun, 1 Jun 2003 15:10:51 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org Message-ID: <20030601221051.GA975@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: libthr: ia64 port: trapframe 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: Sun, 01 Jun 2003 22:10:53 -0000 Gang, After implementing cpu_thread_setup() as Mike pointed out I hit upon another snafu. In kern_thr.c:thr_create() we copy the trapframe over from the currently running thread (td) to the newly created thread (td0). This however cannot be done on ia64: On ia64 we can have a nested fault when trying to contruct a trapframe. A nested fault is icky, because the CPU does not save any state (it would otherwise clobber the state of the original trap/interrupt). This also means that we have to know exactly what can cause a nested fault so that we know what the faulting address is and where we have to jump to when we inserted a TLB. This means that we have to make sure that a trapframe does not cross a page boundary, because otherwise we can have a nested fault any place we write into the trapframe. To solve this, we align the trapframe on a 1KB boundary. Now the crux: if we align the trapframe, we don't know how much the delta is from the previous stack pointer to the bottom of the trapframe and hence the new stack pointer. This itself is not really a problem, but we need to know this delta if we want to restore the stack pointer to the value it had prior to the trap (we're talking kernel stack pointer). Therefore, we save the length of the trapframe (ie the delta) in the trapframe itself. By copying trapframes, we also copy the length of the trapframe, which is generally bad. The new trapframe is not 1KB aligned (we know up front it will be contained in a single page) and thus will have a fixed length (sizeof(struct trapframe)). However the trapframe we copy from has been 1KB aligned and is generally larger than sizeof(trapframe). Anyway: the end result is that if we enter userland with a thread created by thr_create, we clobber our PCB because we incorrectly updated the stack pointer. The following solutions exist: 1. quick and dirty: ------------------- We know that the new trapframe is sizeof(struct trapframe) long, so we simply correct the length after copying: Index: kern_thr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_thr.c,v retrieving revision 1.8 diff -u -r1.8 kern_thr.c --- kern_thr.c 16 May 2003 21:26:42 -0000 1.8 +++ kern_thr.c 1 Jun 2003 22:02:46 -0000 @@ -157,6 +157,9 @@ td0->td_sigmask = td->td_sigmask; PROC_UNLOCK(td->td_proc); bcopy(td->td_frame, td0->td_frame, sizeof(struct trapframe)); +#ifdef __ia64__ + td0->td_frame->tf_length = sizeof(struct trapframe); +#endif td0->td_ucred = crhold(td->td_ucred); /* Initialize our kse structure. */ 2. cpu__set_upcall() change: ---------------------------- We have all the MD specifics in cpu_set_upcall, so we move the copying of the trapframe to cpu_set_upcall(). This means we need to change its prototype to either void cpu_set_upcall(struct thread *new, struct thread *old) or void cpu_set_upcall(struct thread *new, struct pcb *pcb, struct trapframe *tf) I don't know if we can simply remove the copying of the trapframe and have it happen after crhold() and kse_alloc() or that we need to move the call to cpu_set_upcall() up to before kse_alloc() and/or crhold(). In other words: I don't know if we have a phase ordering problem if we delay copying the trapframe until we call cpu_set_upcall() Thought? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Mon Jun 2 01:06:25 2003 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 9BAC237B401; Mon, 2 Jun 2003 01:06:25 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F4DC43F3F; Mon, 2 Jun 2003 01:06:24 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h5286KEU059134; Mon, 2 Jun 2003 10:06:21 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 2 Jun 2003 10:06:20 +0200 (CEST) From: Martin Blapp To: Alexander Kabaev In-Reply-To: <20030601095725.08bcc523.kabaev@mail.ru> Message-ID: <20030602100458.R71313@cvs.imp.ch> References: <20030601112540.V94836@cvs.imp.ch> <20030601095725.08bcc523.kabaev@mail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: vm-related panic with 5.1RC1 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, 02 Jun 2003 08:06:26 -0000 Hi, > This is exactly the panic I am seeing on my dual-processor box. My > current suspicion is that it somehow relates to the same pcb_ext being > freed twice. I do not need OpenOffice to trigger the bug, on SMP > configuration it happens all the time. In the meantime the box did not panic anymore. Can you look and try if limiting maxmem makes anything different on the SMP box ? cat /boot/loader.conf hw.physmem=256M I think it's coincidence, but who knows ... Martin From owner-freebsd-threads@FreeBSD.ORG Mon Jun 2 09:24:52 2003 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 F276937B401; Mon, 2 Jun 2003 09:24:51 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 635DB43FBF; Mon, 2 Jun 2003 09:24:50 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 19MqVS-0007J5-00; Mon, 2 Jun 2003 07:41:50 -0700 Date: Mon, 2 Jun 2003 07:41:48 -0700 (PDT) From: Tom Samplonius To: Sheldon Hearn In-Reply-To: <20030602123445.GK84604@starjuice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: freebsd-java@FreeBSD.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 02 Jun 2003 16:24:52 -0000 ... > And I encourage the java developers to let us threads guys know > what they're having problems with. It has been stated that > jdk is not guaranteed to work with anything but libc_r, so > contact us over at threads@. We want to see a fast and stable > jdk as much as anyone else does. > > -- > Dan Eischen But the last that I've seen on the threads@ list is that libkse's signal handling is not finished, and both libthr and libkse have incomplete SMP support. I've been waiting to hear whether one of these has reached a "finished" state, in order that a test build of jdk on FreeBSD 5 is not a total waste... Tom From owner-freebsd-threads@FreeBSD.ORG Mon Jun 2 16:11:18 2003 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 6A37837B404 for ; Mon, 2 Jun 2003 16:11:16 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C242943F3F for ; Mon, 2 Jun 2003 16:11:15 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h52NBFw12336 for ; Mon, 2 Jun 2003 19:11:15 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 2 Jun 2003 19:11:15 -0400 (EDT) From: Jeff Roberson To: threads@freebsd.org Message-ID: <20030602191018.O69975-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Updated umtx 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, 02 Jun 2003 23:11:18 -0000 UMTX has been causing some problems for libthr. Especially on SMP. Please try the updated version of umtx at: http://www.chesapeake.net/~jroberson/kern_umtx.c This should be a drop in replacement for 5.1 or -CURRENT. Thanks, Jeff From owner-freebsd-threads@FreeBSD.ORG Mon Jun 2 16:23:06 2003 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 2FD9137B401; Mon, 2 Jun 2003 16:23:06 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F6B43F93; Mon, 2 Jun 2003 16:23:05 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h52NN3Nc018882; Mon, 2 Jun 2003 19:23:03 -0400 (EDT) Date: Mon, 2 Jun 2003 19:23:03 -0400 (EDT) From: Daniel Eischen To: Tom Samplonius In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sheldon Hearn cc: freebsd-java@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 02 Jun 2003 23:23:06 -0000 On Mon, 2 Jun 2003, Tom Samplonius wrote: > ... > > And I encourage the java developers to let us threads guys know > > what they're having problems with. It has been stated that > > jdk is not guaranteed to work with anything but libc_r, so > > contact us over at threads@. We want to see a fast and stable > > jdk as much as anyone else does. > > > > -- > > Dan Eischen > > > But the last that I've seen on the threads@ list is that libkse's signal > handling is not finished, and both libthr and libkse have incomplete SMP > support. I've been waiting to hear whether one of these has reached a > "finished" state, in order that a test build of jdk on FreeBSD 5 is not a > total waste... SMP libkse support should be complete. We are working on signal handling now, but it's fudged to mostly work. Mozilla, KDE, and openoffice all run with libkse. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jun 2 20:07:41 2003 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 EF79537B401 for ; Mon, 2 Jun 2003 20:07:41 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C41443F3F for ; Mon, 2 Jun 2003 20:07:41 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h5337eK44341 for ; Mon, 2 Jun 2003 23:07:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 2 Jun 2003 23:07:40 -0400 (EDT) From: Jeff Roberson To: threads@freebsd.org In-Reply-To: <20030602191018.O69975-100000@mail.chesapeake.net> Message-ID: <20030602230546.Y69975-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Updated umtx 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, 03 Jun 2003 03:07:42 -0000 mozilla works on SMP+thr just fine now. See http://www.chesapeake.net/~jroberson/umtxlocks.diff On Mon, 2 Jun 2003, Jeff Roberson wrote: > UMTX has been causing some problems for libthr. Especially on SMP. > Please try the updated version of umtx at: > > http://www.chesapeake.net/~jroberson/kern_umtx.c > > This should be a drop in replacement for 5.1 or -CURRENT. > > Thanks, > Jeff > > _______________________________________________ > 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 Mon Jun 2 22:02:16 2003 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 8BD5D37B401; Mon, 2 Jun 2003 22:02:16 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B51743F93; Mon, 2 Jun 2003 22:02:14 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 19N2KL-0000m9-00; Mon, 2 Jun 2003 20:19:09 -0700 Date: Mon, 2 Jun 2003 20:19:08 -0700 (PDT) From: Tom Samplonius To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sheldon Hearn cc: freebsd-java@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 03 Jun 2003 05:02:16 -0000 On Mon, 2 Jun 2003, Daniel Eischen wrote: > On Mon, 2 Jun 2003, Tom Samplonius wrote: > > ... > > > And I encourage the java developers to let us threads guys know > > > what they're having problems with. It has been stated that > > > jdk is not guaranteed to work with anything but libc_r, so > > > contact us over at threads@. We want to see a fast and stable > > > jdk as much as anyone else does. > > > > > > -- > > > Dan Eischen > > > > > > But the last that I've seen on the threads@ list is that libkse's signal > > handling is not finished, and both libthr and libkse have incomplete SMP > > support. I've been waiting to hear whether one of these has reached a > > "finished" state, in order that a test build of jdk on FreeBSD 5 is not a > > total waste... > > SMP libkse support should be complete. We are working on signal > handling now, but it's fudged to mostly work. Mozilla, KDE, > and openoffice all run with libkse. Does "fudged" mean that the issue MySQL not exiting has also been resolved? That seems like something that would break a java application real fast. Also at what point was support completed? I'm not sure if I need to cvsup again. I last cvsupped -current on May 31st. Would that be the latest and greatest libkse? > -- > Dan Eischen Tom From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 02:48:18 2003 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 E1AFA37B401; Tue, 3 Jun 2003 02:48:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB33443F93; Tue, 3 Jun 2003 02:48:17 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h539mFNc013617; Tue, 3 Jun 2003 05:48:15 -0400 (EDT) Date: Tue, 3 Jun 2003 05:48:15 -0400 (EDT) From: Daniel Eischen To: Tom Samplonius In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sheldon Hearn cc: freebsd-java@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 03 Jun 2003 09:48:19 -0000 On Mon, 2 Jun 2003, Tom Samplonius wrote: > > On Mon, 2 Jun 2003, Daniel Eischen wrote: > > > On Mon, 2 Jun 2003, Tom Samplonius wrote: > > > ... > > > > And I encourage the java developers to let us threads guys know > > > > what they're having problems with. It has been stated that > > > > jdk is not guaranteed to work with anything but libc_r, so > > > > contact us over at threads@. We want to see a fast and stable > > > > jdk as much as anyone else does. > > > > > > > > -- > > > > Dan Eischen > > > > > > > > > But the last that I've seen on the threads@ list is that libkse's signal > > > handling is not finished, and both libthr and libkse have incomplete SMP > > > support. I've been waiting to hear whether one of these has reached a > > > "finished" state, in order that a test build of jdk on FreeBSD 5 is not a > > > total waste... > > > > SMP libkse support should be complete. We are working on signal > > handling now, but it's fudged to mostly work. Mozilla, KDE, > > and openoffice all run with libkse. > > Does "fudged" mean that the issue MySQL not exiting has also been > resolved? That seems like something that would break a java application > real fast. I believe mysql relies on SIGHUP or a fork to handle signals. Mysql may actually work now, but I haven't tried it. I don't think the JDK relies on signals other than synchronous signals which should work OK with libkse. I was more interested in the statement that "jdk is only guaranteed to work with libc_r" that one of the Java developers posted. I took it to mean that the implementation of our jdk is geared towards libc_r (perhaps knowing internal stuff about how libc_r works). I don't want anything like that to stop us, and we can add some common APIs to the threads libraries if needed to support it. > Also at what point was support completed? I'm not sure if I need to > cvsup again. I last cvsupped -current on May 31st. Would that be the > latest and greatest libkse? That should be good. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 06:07:43 2003 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 A253237B401 for ; Tue, 3 Jun 2003 06:07:43 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B56B43F3F for ; Tue, 3 Jun 2003 06:07:40 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h53D7bl00741 for ; Tue, 3 Jun 2003 10:07:37 -0300 Message-ID: <3EDC9D99.2020102@tcoip.com.br> Date: Tue, 03 Jun 2003 10:07:37 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030416 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: libc_r, libthr & konsole news] 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, 03 Jun 2003 13:07:44 -0000 I'm at loss at how dup2() works, exactly. It seems that libc_r overrides it, but libthr doesn't. But I don't understand the process well, because I'm don't understand the syscall glue. -------- Original Message -------- Subject: libc_r, libthr & konsole news Date: Tue, 03 Jun 2003 09:47:43 -0300 From: Daniel C. Sobral To: CURRENT Alas, I found *what* is going on differently depending on the library used. With libc_r, dup2() gets called and fails, preventing execution of konsole_grantpty, with libthr things work, konsole_grantpty gets called and... ttyname fails. :-) Now, dup2() implementation seems to differ between libc_r and libthr (though I'm open to be shown that is not so -- I don't quite understand how things work here). I have verified that by preventing execution of /usr/local/bin/konsole_grantpty (by the simple artifice of renaming it), the problem DOES NOT HAPPEN. Now... to find out what's different between both dup2() implementations... -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net "I think sex is better than logic, but I can't prove it." _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Hate the sin and love the sinner. -- Mahatma Gandhi From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 08:52:03 2003 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 EB9BD37B401; Tue, 3 Jun 2003 08:52:03 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C68143F3F; Tue, 3 Jun 2003 08:52:02 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h53FpxDX028529; Tue, 3 Jun 2003 18:52:00 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3EDCC41F.9060706@he.iki.fi> Date: Tue, 03 Jun 2003 18:51:59 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-threads@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: RELENG_4 to RELENG_5_1 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, 03 Jun 2003 15:52:04 -0000 I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c -o lock.So building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 09:02:47 2003 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 818B237B401; Tue, 3 Jun 2003 09:02:47 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86DCD43F93; Tue, 3 Jun 2003 09:02:46 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h53G2i3D054642; Tue, 3 Jun 2003 12:02:44 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h53G2iKv054641; Tue, 3 Jun 2003 12:02:44 -0400 (EDT) Date: Tue, 3 Jun 2003 12:02:44 -0400 From: Alexander Kabaev To: Petri Helenius Message-Id: <20030603120244.26423a3e.ak03@gte.com> In-Reply-To: <3EDCC41F.9060706@he.iki.fi> References: <3EDCC41F.9060706@he.iki.fi> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws156 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: RELENG_4 to RELENG_5_1 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, 03 Jun 2003 16:02:47 -0000 On Tue, 03 Jun 2003 18:51:59 +0300 Petri Helenius wrote: > I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make > buildworld compiles > a while and then stops with: > > Question is if this is supported and if yes, what should I do > differently? > > Pete Got your buildworld log saved somewhere? Could you send it to me please. -- Alexander Kabaev From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 09:32:56 2003 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 9E3C537B401; Tue, 3 Jun 2003 09:32:56 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D705543FBD; Tue, 3 Jun 2003 09:32:54 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 19ND6f-0000qM-00; Tue, 3 Jun 2003 07:49:45 -0700 Date: Tue, 3 Jun 2003 07:49:41 -0700 (PDT) From: Tom Samplonius To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sheldon Hearn cc: freebsd-java@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 03 Jun 2003 16:32:57 -0000 On Tue, 3 Jun 2003, Daniel Eischen wrote: ... > I was more interested in the statement that "jdk is only guaranteed > to work with libc_r" that one of the Java developers posted. I > took it to mean that the implementation of our jdk is geared > towards libc_r (perhaps knowing internal stuff about how libc_r > works). I don't want anything like that to stop us, and we > can add some common APIs to the threads libraries if needed > to support it. I don't think jdk uses any libc_r internals. I believe it is just that jdk1.4.1 is a very large and very complex application, and the jdk developers don't want to have to track libkse/libthr issues when jdk1.4.1 is still beta and requires plenty more work. I know the Java developers are trying to get jdk1.4.1 to the point it can pass Sun's TCK, so it can be distributed as a binary. > -- > Dan Eischen Tom From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 10:39:56 2003 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 7E8A837B401 for ; Tue, 3 Jun 2003 10:39:56 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B706143F75 for ; Tue, 3 Jun 2003 10:39:55 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h53HdqNc023698; Tue, 3 Jun 2003 13:39:54 -0400 (EDT) Date: Tue, 3 Jun 2003 13:39:52 -0400 (EDT) From: Daniel Eischen To: "Daniel C. Sobral" In-Reply-To: <3EDC9D99.2020102@tcoip.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: [Fwd: libc_r, libthr & konsole news] 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, 03 Jun 2003 17:39:56 -0000 On Tue, 3 Jun 2003, Daniel C. Sobral wrote: > I'm at loss at how dup2() works, exactly. It seems that libc_r overrides > it, but libthr doesn't. But I don't understand the process well, because > I'm don't understand the syscall glue. Can you test libkse as well? I know that dup2 is not overridden in libkse either. I have a patch for signals at: http://people.freebsd.org/~deischen/kse/sig.diffs that you might want to apply first. It lets konsole run and put up a dialog if the chown fails (at least it works for me). -- Dan Eischen > -------- Original Message -------- > Subject: libc_r, libthr & konsole news > Date: Tue, 03 Jun 2003 09:47:43 -0300 > From: Daniel C. Sobral > To: CURRENT > > Alas, I found *what* is going on differently depending on the library used. > > With libc_r, dup2() gets called and fails, preventing execution of > konsole_grantpty, with libthr things work, konsole_grantpty gets called > and... ttyname fails. :-) > > Now, dup2() implementation seems to differ between libc_r and libthr > (though I'm open to be shown that is not so -- I don't quite understand > how things work here). > > I have verified that by preventing execution of > /usr/local/bin/konsole_grantpty (by the simple artifice of renaming it), > the problem DOES NOT HAPPEN. > > Now... to find out what's different between both dup2() implementations... > > -- > Daniel C. Sobral (8-DCS) > Gerencia de Operacoes > Divisao de Comunicacao de Dados > Coordenacao de Seguranca > VIVO Centro Oeste Norte > Fones: 55-61-313-7654/Cel: 55-61-9618-0904 > E-mail: Daniel.Capo@tco.net.br > Daniel.Sobral@tcoip.com.br > dcs@tcoip.com.br > > Outros: > dcs@newsguy.com > dcs@freebsd.org > capo@notorious.bsdconspiracy.net > > "I think sex is better than logic, but I can't prove it." > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Daniel C. Sobral (8-DCS) > Gerencia de Operacoes > Divisao de Comunicacao de Dados > Coordenacao de Seguranca > VIVO Centro Oeste Norte > Fones: 55-61-313-7654/Cel: 55-61-9618-0904 > E-mail: Daniel.Capo@tco.net.br > Daniel.Sobral@tcoip.com.br > dcs@tcoip.com.br > > Outros: > dcs@newsguy.com > dcs@freebsd.org > capo@notorious.bsdconspiracy.net > > Hate the sin and love the sinner. > -- Mahatma Gandhi > > _______________________________________________ > 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 3 10:53:51 2003 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 8E02E37B404; Tue, 3 Jun 2003 10:53:51 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 881C843F85; Tue, 3 Jun 2003 10:53:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc02) with ESMTP id <2003060317534700200aei15e>; Tue, 3 Jun 2003 17:53:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA93298; Tue, 3 Jun 2003 10:53:46 -0700 (PDT) Date: Tue, 3 Jun 2003 10:53:44 -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: freebsd-threads@freebsd.org cc: Sheldon Hearn cc: freebsd-java@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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, 03 Jun 2003 17:53:52 -0000 On Tue, 3 Jun 2003, Daniel Eischen wrote: > On Mon, 2 Jun 2003, Tom Samplonius wrote: > > > > > On Mon, 2 Jun 2003, Daniel Eischen wrote: > > > > > On Mon, 2 Jun 2003, Tom Samplonius wrote: > > > > ... > > > > > And I encourage the java developers to let us threads guys know > > > > > what they're having problems with. It has been stated that > > > > > jdk is not guaranteed to work with anything but libc_r, so > > > > > contact us over at threads@. We want to see a fast and stable > > > > > jdk as much as anyone else does. > > > > > > > > > > -- > > > > > Dan Eischen > > > > > > > > > > > > But the last that I've seen on the threads@ list is that libkse's signal > > > > handling is not finished, and both libthr and libkse have incomplete SMP > > > > support. I've been waiting to hear whether one of these has reached a > > > > "finished" state, in order that a test build of jdk on FreeBSD 5 is not a > > > > total waste... > > > > > > SMP libkse support should be complete. We are working on signal > > > handling now, but it's fudged to mostly work. Mozilla, KDE, > > > and openoffice all run with libkse. > > > > Does "fudged" mean that the issue MySQL not exiting has also been > > resolved? That seems like something that would break a java application > > real fast. > > I believe mysql relies on SIGHUP or a fork to handle signals. Mysql > may actually work now, but I haven't tried it. I don't think the JDK > relies on signals other than synchronous signals which should work > OK with libkse. > > I was more interested in the statement that "jdk is only guaranteed > to work with libc_r" that one of the Java developers posted. I > took it to mean that the implementation of our jdk is geared > towards libc_r (perhaps knowing internal stuff about how libc_r > works). I don't want anything like that to stop us, and we > can add some common APIs to the threads libraries if needed > to support it. > > > Also at what point was support completed? I'm not sure if I need to > > cvsup again. I last cvsupped -current on May 31st. Would that be the > > latest and greatest libkse? > > That should be good. A panic fix was checked in yesterday that should be included, so today's is a better bet.. > > -- > 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 3 11:02:44 2003 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 9EBEE37B401 for ; Tue, 3 Jun 2003 11:02:44 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8334E43F85 for ; Tue, 3 Jun 2003 11:02:43 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h53I2g3D065424; Tue, 3 Jun 2003 14:02:42 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h53I2gDH065423; Tue, 3 Jun 2003 14:02:42 -0400 (EDT) Date: Tue, 3 Jun 2003 14:02:42 -0400 From: Alexander Kabaev To: Daniel Eischen Message-Id: <20030603140242.04780560.ak03@gte.com> In-Reply-To: References: <3EDC9D99.2020102@tcoip.com.br> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws156 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: [Fwd: libc_r, libthr & konsole news] 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, 03 Jun 2003 18:02:45 -0000 On Tue, 3 Jun 2003 13:39:52 -0400 (EDT) Daniel Eischen wrote: > http://people.freebsd.org/~deischen/kse/sig.diffs I wonder if NSIG should be _SIG_MAXSIG instead. NSIG is defined as 32, FreeBSD supports more signals than that. -- Alexander Kabaev From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 11:10:09 2003 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 2E9AB37B401 for ; Tue, 3 Jun 2003 11:10:09 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09CB643F75 for ; Tue, 3 Jun 2003 11:10:06 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h53I9ol08294; Tue, 3 Jun 2003 15:09:50 -0300 Message-ID: <3EDCE46E.3040109@tcoip.com.br> Date: Tue, 03 Jun 2003 15:09:50 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030416 X-Accept-Language: en-us, en, pt-br, ja 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: threads@freebsd.org Subject: Re: [Fwd: libc_r, libthr & konsole news] 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, 03 Jun 2003 18:10:09 -0000 Daniel Eischen wrote: > On Tue, 3 Jun 2003, Daniel C. Sobral wrote: > > >>I'm at loss at how dup2() works, exactly. It seems that libc_r overrides >>it, but libthr doesn't. But I don't understand the process well, because >>I'm don't understand the syscall glue. > > > Can you test libkse as well? I know that dup2 is not overridden in > libkse either. I saw the problem with libkse earlier. I haven't tested again, but it looked the same as libthr. Basically, dup2() fails, for reasons unknown (and ak03, for one, thinks the bug is libc_r's) with libc_r, causing it not to call konsole_grantpty. When that happens, ttyname() called later works. With libthr, the dup2() doesn't fail, konsole_grantpty gets called, and ttyname() fails. This happens only one time for each pty/tty. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net "I like being single. I'm always there when I need me." -- Art Leo From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 11:20:36 2003 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 ED25837B404 for ; Tue, 3 Jun 2003 11:20:36 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503A143F3F for ; Tue, 3 Jun 2003 11:20:35 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h53IJql08534; Tue, 3 Jun 2003 15:19:52 -0300 Message-ID: <3EDCE6C7.4050209@tcoip.com.br> Date: Tue, 03 Jun 2003 15:19:51 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030416 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: libc_r, libthr & konsole news 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, 03 Jun 2003 18:20:37 -0000 Julian Elischer wrote: > > On Tue, 3 Jun 2003, Daniel C. Sobral wrote: > > >>Alas, I found *what* is going on differently depending on the library used. >> >>With libc_r, dup2() gets called and fails, preventing execution of >>konsole_grantpty, with libthr things work, konsole_grantpty gets called >>and... ttyname fails. :-) >> >>Now, dup2() implementation seems to differ between libc_r and libthr >>(though I'm open to be shown that is not so -- I don't quite understand >>how things work here). >> >>I have verified that by preventing execution of >>/usr/local/bin/konsole_grantpty (by the simple artifice of renaming it), >>the problem DOES NOT HAPPEN. >> >>Now... to find out what's different between both dup2() implementations... > > > does it work with kse? /me sighs Ok, ok, I'll test it. And I tested it. Now, libkse had problems freezing konsole at one time. I don't know about now, but that's another matter anyway. Both libkse and libthr behave identically with regards to the problem I described. In both dup2() works, resulting in later failure of ttyname(), and in both just renaming /usr/local/bin/konsole_grantpty results in ttyname() working again. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Class schedules are designed so that every student will waste the maximum time between classes. From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 12:19:50 2003 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 C7C8F37B401 for ; Tue, 3 Jun 2003 12:19:50 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E885043FA3 for ; Tue, 3 Jun 2003 12:19:49 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h53JJnNc010861; Tue, 3 Jun 2003 15:19:49 -0400 (EDT) Date: Tue, 3 Jun 2003 15:19:49 -0400 (EDT) From: Daniel Eischen To: Alexander Kabaev In-Reply-To: <20030603140242.04780560.ak03@gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: [Fwd: libc_r, libthr & konsole news] 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, 03 Jun 2003 19:19:51 -0000 On Tue, 3 Jun 2003, Alexander Kabaev wrote: > On Tue, 3 Jun 2003 13:39:52 -0400 (EDT) > Daniel Eischen wrote: > > > http://people.freebsd.org/~deischen/kse/sig.diffs > > I wonder if NSIG should be _SIG_MAXSIG instead. NSIG is defined > as 32, FreeBSD supports more signals than that. Yep, we'll get to that in one swell foop when we add the remaining signal support code. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 12:56:08 2003 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 A9BD437B401; Tue, 3 Jun 2003 12:56:08 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB30C43F75; Tue, 3 Jun 2003 12:56:07 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by attbi.com (sccrmhc01) with ESMTP id <2003060319560600100hrv6te>; Tue, 3 Jun 2003 19:56:07 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h53Ju2ki062909; Tue, 3 Jun 2003 12:56:02 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h53Ju1kA062908; Tue, 3 Jun 2003 12:56:01 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 3 Jun 2003 12:56:01 -0700 From: "Crist J. Clark" To: Alexander Kabaev Message-ID: <20030603195600.GA62620@blossom.cjclark.org> References: <3EDCC41F.9060706@he.iki.fi> <20030603120244.26423a3e.ak03@gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030603120244.26423a3e.ak03@gte.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: RELENG_4 to RELENG_5_1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 19:56:09 -0000 On Tue, Jun 03, 2003 at 12:02:44PM -0400, Alexander Kabaev wrote: > > On Tue, 03 Jun 2003 18:51:59 +0300 > Petri Helenius wrote: > > > I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make > > buildworld compiles > > a while and then stops with: > > > > Question is if this is supported and if yes, what should I do > > differently? > > > > Pete > > Got your buildworld log saved somewhere? Could you send it to me please. Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 13:07:57 2003 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 5553D37B401; Tue, 3 Jun 2003 13:07:57 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6579843F85; Tue, 3 Jun 2003 13:07:56 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h53K7t3D067564; Tue, 3 Jun 2003 16:07:55 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h53K7tsx067563; Tue, 3 Jun 2003 16:07:55 -0400 (EDT) Date: Tue, 3 Jun 2003 16:07:54 -0400 From: Alexander Kabaev To: "Crist J. Clark" Message-Id: <20030603160754.3b4da1c4.ak03@gte.com> In-Reply-To: <20030603195600.GA62620@blossom.cjclark.org> References: <3EDCC41F.9060706@he.iki.fi> <20030603120244.26423a3e.ak03@gte.com> <20030603195600.GA62620@blossom.cjclark.org> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws156 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: crist.clark@attbi.com cc: freebsd-threads@freebsd.org Subject: Re: RELENG_4 to RELENG_5_1 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, 03 Jun 2003 20:07:57 -0000 On Tue, 3 Jun 2003 12:56:01 -0700 "Crist J. Clark" wrote: > > Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I > have been getting the same failure originally quoted when building > HEAD on RELENG_4 for several days now. > > I suggest that the original poster double-check that he has RELENG_5_1 > and not HEAD. And I do have buildworld logs. I'll send in a separate > mail. No need that. This is a bug and it needs to be fixed. I am working on this. Thanks for the reports. -- Alexander Kabaev From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 17:15:45 2003 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 9239937B401; Tue, 3 Jun 2003 17:15:45 -0700 (PDT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id E019F43F93; Tue, 3 Jun 2003 17:15:44 -0700 (PDT) (envelope-from CooCooCaChoo@myrealbox.com) Received: from matthewymj3upb (210.50.172.108) by smtp02.syd.iprimus.net.au (7.0.015) id 3ECBEA340020EA8E; Wed, 4 Jun 2003 10:15:41 +1000 From: "Matthew Gardiner" To: "Alexander Kabaev" , "Crist J. Clark" Date: Wed, 4 Jun 2003 10:15:41 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030603160754.3b4da1c4.ak03@gte.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-current@freebsd.org cc: crist.clark@attbi.com cc: freebsd-threads@freebsd.org Subject: RE: RELENG_4 to RELENG_5_1 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, 04 Jun 2003 00:15:45 -0000 >> >> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I >> have been getting the same failure originally quoted when building >> HEAD on RELENG_4 for several days now. >> >> I suggest that the original poster double-check that he has RELENG_5_1 >> and not HEAD. And I do have buildworld logs. I'll send in a separate >> mail. > > No need that. This is a bug and it needs to be fixed. I am working on > this. Thanks for the reports. Just a quick question, what version of GCC is going to appear in FreeBSD 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its stability) will be used for 5.2. Could someone either confirm or correct me on this assumption? Matthew Gardiner From owner-freebsd-threads@FreeBSD.ORG Tue Jun 3 17:26:34 2003 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 7A0F537B401; Tue, 3 Jun 2003 17:26:34 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE66D43F75; Tue, 3 Jun 2003 17:26:33 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by attbi.com (rwcrmhc52) with ESMTP id <2003060400263305200r11aoe>; Wed, 4 Jun 2003 00:26:33 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h540QWki063687; Tue, 3 Jun 2003 17:26:32 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h540QV99063686; Tue, 3 Jun 2003 17:26:31 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 3 Jun 2003 17:26:31 -0700 From: "Crist J. Clark" To: Matthew Gardiner Message-ID: <20030604002631.GA63674@blossom.cjclark.org> References: <20030603160754.3b4da1c4.ak03@gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: RELENG_4 to RELENG_5_1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 00:26:34 -0000 On Wed, Jun 04, 2003 at 10:15:41AM +1000, Matthew Gardiner wrote: > >> > >> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I > >> have been getting the same failure originally quoted when building > >> HEAD on RELENG_4 for several days now. > >> > >> I suggest that the original poster double-check that he has RELENG_5_1 > >> and not HEAD. And I do have buildworld logs. I'll send in a separate > >> mail. > > > > No need that. This is a bug and it needs to be fixed. I am working on > > this. Thanks for the reports. > > Just a quick question, what version of GCC is going to appear in FreeBSD > 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its > stability) will be used for 5.2. Could someone either confirm or correct me > on this assumption? gcc 3.2.2 is in RELENG_5_1. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 05:38:48 2003 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 7492C37B401 for ; Wed, 4 Jun 2003 05:38:48 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD3C743FA3 for ; Wed, 4 Jun 2003 05:38:46 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54Ccjv14191 for ; Wed, 4 Jun 2003 14:38:45 +0200 From: Kern Sibbald To: freebsd-threads@freebsd.org Content-Type: multipart/mixed; boundary="=-3yPEbVH5Pe+LqlZXsJlK" Organization: Message-Id: <1054730325.13630.456.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 14:38:45 +0200 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 12:38:48 -0000 --=-3yPEbVH5Pe+LqlZXsJlK Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I've run into what I consider a bug in the FreeBSD implementation of pthreads and pthread_equal() in particular. Basically, pthread_equal() will return true even if it is not the same thread. This can occur when one thread dies and another one starts. The second thread then takes on the exact identity of the the first thread, and pthread_equal() returns true for a case where it is a different thread. You may argue that the first thread is dead so its thread id is no longer valid. True, but think about how Unix would work if every process started up with the process id of the last process to exit. Even if someone were to claim that this case is undefined, I would say fine, but it is rather trivial to ensure that pthread_equal() returns false unless the thread is really physically the same thread, you just need one variable in pthread_t that is incremented for each new thread, so why not do it "the right way". This bug exists in the FreeBSD implementation but not in Linux or in Solaris. I've worked around the bug so this is not a critical issue for me. I've attached a simple program that illustrates this problem. Don't hesitate to ask if you have any questions, but please be aware that I am not subscribed to the list. Best regards, Kern Switzerland --=-3yPEbVH5Pe+LqlZXsJlK-- From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 06:52:09 2003 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 9E90037B401 for ; Wed, 4 Jun 2003 06:52:09 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id D859F43FA3 for ; Wed, 4 Jun 2003 06:52:08 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.93.237]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net>; Wed, 4 Jun 2003 08:52:08 -0500 Date: Wed, 4 Jun 2003 09:52:07 -0400 From: Mike Makonnen To: Kern Sibbald In-Reply-To: <1054730325.13630.456.camel@rufus> References: <1054730325.13630.456.camel@rufus> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.93.237] at Wed, 4 Jun 2003 08:52:07 -0500 Message-Id: <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 13:52:09 -0000 >From the new linux NPTL: ================= typedef struct __opaque_pthread *pthread_t; int __pthread_equal (thread1, thread2) pthread_t thread1; pthread_t thread2; { return thread1 == thread2; } strong_alias (__pthread_equal, pthread_equal) >From FreeBSD's libc_r implementation: ========================== typedef struct pthread *pthread_t; __weak_reference(_pthread_equal, pthread_equal); int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } In both implementations pthread_t is a pointer to a memory location. So, your inability to reproduce this on Linux is probably an accident and not an intentional feature. If the two threads (i.e. the dead one and the new one point to the same memory location using unique id's is not going to solve the problem because both pointers will be pointing to the same structure (and therefore the same unique id, even though it will be a different id after the second thread is created). The only fool-proof way to do this is to make pthread_t a proper structure containing a unique id and a pointer to a thread structure, but that would mean passing a structure on the stack (which is not necessarily bad in itself, but means someone would have to go through all the threads libraries and modify appropriately). On the other hand I may be mistaken and there may be an easy way to achieve this :-) Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 07:15:28 2003 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 2035E37B401 for ; Wed, 4 Jun 2003 07:15:28 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01FA43F93 for ; Wed, 4 Jun 2003 07:15:26 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54EFEv14730; Wed, 4 Jun 2003 16:15:14 +0200 From: Kern Sibbald To: Mike Makonnen In-Reply-To: <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> References: <1054730325.13630.456.camel@rufus> <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> Content-Type: text/plain Organization: Message-Id: <1054736114.13630.499.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 16:15:14 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 14:15:28 -0000 Hello, I doubt that this is an accident on Solaris and Linux. They are both excellent implementations (though different) of pthreads, and it is very clear from the values contained that they are not simple memory addresses and are designed to be unique. How they get to their internal structures I don't know and probably it is a few cycles faster than FreeBSD, but it makes pthread_equal() work correctly on their systems. I can say that their numbers are unique over a very large number of threads, and they repeat perfectly for each execution of the program so it isn't likely to be anything left to chance. See my notes below: On Wed, 2003-06-04 at 15:52, Mike Makonnen wrote: > >From the new linux NPTL: > >From the new linux NPTL: > ================= > typedef struct __opaque_pthread *pthread_t; > int > __pthread_equal (thread1, thread2) > pthread_t thread1; > pthread_t thread2; > { > return thread1 == thread2; > } > strong_alias (__pthread_equal, pthread_equal) > > > >From FreeBSD's libc_r implementation: > ========================== > typedef struct pthread *pthread_t; > __weak_reference(_pthread_equal, pthread_equal); > > int > _pthread_equal(pthread_t t1, pthread_t t2) > { > /* Compare the two thread pointers: */ > return (t1 == t2); > } > > In both implementations pthread_t is a pointer to a memory location. > So, your inability to reproduce this on Linux is probably an accident and not an > intentional feature. > > If the two threads (i.e. the dead one and the new one point to the same memory > location using unique id's is not going to solve the problem because both > pointers will be pointing to the same structure (and therefore the same unique > id, even though it will be a different id after the second thread is created). > > The only fool-proof way to do this is to make pthread_t a proper structure > containing a unique id and a pointer to a thread structure, but that would mean > passing a structure on the stack (which is not necessarily bad in itself, > but means someone would have to go through all the threads libraries and > modify appropriately). On Linux, the above is not true. The pthread_id is : typedef unsigned long int pthread_t; > On the other hand I may be mistaken and there may be an easy way to achieve > this :-) Yup, there must be judging by the above. As previously mentioned, I'm not convinced this is something urgent, but I am convinced it is a bug. However, it certainly bit me and took me a bit to figure out. Best regards, Kern From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 07:58:40 2003 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 476AD37B401 for ; Wed, 4 Jun 2003 07:58:40 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7539D43F85 for ; Wed, 4 Jun 2003 07:58:39 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.93.237]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030604145838.NUHK3199.pop016.verizon.net@kokeb.ambesa.net>; Wed, 4 Jun 2003 09:58:38 -0500 Date: Wed, 4 Jun 2003 10:58:37 -0400 From: Mike Makonnen To: Kern Sibbald In-Reply-To: <1054736114.13630.499.camel@rufus> References: <1054730325.13630.456.camel@rufus> <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> <1054736114.13630.499.camel@rufus> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [138.88.93.237] at Wed, 4 Jun 2003 09:58:38 -0500 Message-Id: <20030604145838.NUHK3199.pop016.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 14:58:40 -0000 On 04 Jun 2003 16:15:14 +0200 Kern Sibbald wrote: > Hello, > > I doubt that this is an accident on Solaris and Linux. > They are both excellent implementations (though different) > of pthreads, and it is very clear from the values contained > that they are not simple memory addresses and are designed > to be unique. I am not talking about Solaris and the comparison I am making is specifically to the NPTL that I believe is supposed to be shipping with Red Hat now. >How they get to their internal structures I > don't know and probably it is a few cycles faster than > FreeBSD, but it makes pthread_equal() work correctly on > their systems. > > I can say that their numbers are unique over a very large > number of threads, and they repeat perfectly for each > execution of the program so it isn't likely to be anything > left to chance. > Can you quote specific code in their Pthreads implementation? Without the actual code, this is all just conjecture. It could be that they simply return an index into an array of thread pointers, but that just means that it takes a lot longer for the numbers to repeat. > As previously mentioned, I'm not convinced this is something urgent, > but I am convinced it is a bug. However, it certainly bit me and > took me a bit to figure out. Maybe and maybe not, but the test program that follows works "correctly" for me. pthread_equal() says the two thread's are not the same. Which also reminds me, I never saw your test program. Can you resend it or put it up on a website? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 08:02:10 2003 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 CFD4437B401 for ; Wed, 4 Jun 2003 08:02:10 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id E745543FB1 for ; Wed, 4 Jun 2003 08:02:09 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.93.237]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030604150209.KLPY11703.pop018.verizon.net@kokeb.ambesa.net>; Wed, 4 Jun 2003 10:02:09 -0500 Date: Wed, 4 Jun 2003 11:02:08 -0400 From: Mike Makonnen To: kern@sibbald.com In-Reply-To: <20030604145838.NUHK3199.pop016.verizon.net@kokeb.ambesa.net> References: <1054730325.13630.456.camel@rufus> <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> <1054736114.13630.499.camel@rufus> <20030604145838.NUHK3199.pop016.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [138.88.93.237] at Wed, 4 Jun 2003 10:02:08 -0500 Message-Id: <20030604150209.KLPY11703.pop018.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 15:02:11 -0000 This time with the test program attached. Sorry. On Wed, 4 Jun 2003 10:58:37 -0400 Mike Makonnen wrote: > On 04 Jun 2003 16:15:14 +0200 > Kern Sibbald wrote: > > > Hello, > > > > I doubt that this is an accident on Solaris and Linux. > > They are both excellent implementations (though different) > > of pthreads, and it is very clear from the values contained > > that they are not simple memory addresses and are designed > > to be unique. > > I am not talking about Solaris and the comparison I am making is specifically > to the NPTL that I believe is supposed to be shipping with Red Hat now. > > >How they get to their internal structures I > > don't know and probably it is a few cycles faster than > > FreeBSD, but it makes pthread_equal() work correctly on > > their systems. > > > > I can say that their numbers are unique over a very large > > number of threads, and they repeat perfectly for each > > execution of the program so it isn't likely to be anything > > left to chance. > > > > Can you quote specific code in their Pthreads implementation? > Without the actual code, this is all just conjecture. It could be that they > simply return an index into an array of thread pointers, but that just means > that it takes a lot longer for the numbers to repeat. > > > As previously mentioned, I'm not convinced this is something urgent, > > but I am convinced it is a bug. However, it certainly bit me and > > took me a bit to figure out. > > Maybe and maybe not, but the test program that follows works "correctly" for > me. pthread_equal() says the two thread's are not the same. Which also > reminds me, I never saw your test program. Can you resend it or put it up on a > website? > > Cheers. > -- > Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc > mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 > mtm@FreeBSD.Org| FreeBSD - The Power To Serve > _______________________________________________ > 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" #include #include void * null(void *arg) { return (NULL); } int main(int argc, char **argv) { pthread_t th1, th2; int error; error = pthread_create(&th1, NULL, null, NULL); if (error != 0) abort(); /* give it a chance to exit */ sleep(3); error = pthread_create(&th2, NULL, null, NULL); if (error != 0) abort(); error = pthread_equal(th1, th2); if (error) printf("They are equal\n"); else printf("They are not equal\n"); return (0); } From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 08:30:48 2003 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 7532437B497 for ; Wed, 4 Jun 2003 08:30:48 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C91F43F85 for ; Wed, 4 Jun 2003 08:30:47 -0700 (PDT) (envelope-from eischen@pcnet.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h54FUiNc014412; Wed, 4 Jun 2003 11:30:44 -0400 (EDT) Date: Wed, 4 Jun 2003 11:30:44 -0400 (EDT) From: Daniel Eischen To: Kern Sibbald In-Reply-To: <1054730325.13630.456.camel@rufus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 15:30:49 -0000 On 4 Jun 2003, Kern Sibbald wrote: > Hello, > > I've run into what I consider a bug in the FreeBSD > implementation of pthreads and pthread_equal() in > particular. Basically, pthread_equal() will return > true even if it is not the same thread. This can occur > when one thread dies and another one starts. The second > thread then takes on the exact identity of the the > first thread, and pthread_equal() returns true for a > case where it is a different thread. You may argue > that the first thread is dead so its thread id is no > longer valid. True, but think about how Unix would > work if every process started up with the process > id of the last process to exit. Process id's can wrap around so it can eventually happen. This is a bug in the application; the implementation is allowed to reuse thread id's and there are enough interfaces for an application to tell when a thread terminates (pthread_join). Perhaps our use of thread id's could be changes so that they were cached at the end of the free thread list, but cacheing them at the front seems to highlight bad applications, so that's a bonus ;-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 09:45:21 2003 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 7942437B401 for ; Wed, 4 Jun 2003 09:45:21 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA17A43F3F for ; Wed, 4 Jun 2003 09:45:19 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54GjFv15149; Wed, 4 Jun 2003 18:45:15 +0200 From: Kern Sibbald To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1054745115.13630.517.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 18:45:15 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 16:45:21 -0000 On Wed, 2003-06-04 at 17:30, Daniel Eischen wrote: > On 4 Jun 2003, Kern Sibbald wrote: > > Hello, > > > > I've run into what I consider a bug in the FreeBSD > > implementation of pthreads and pthread_equal() in > > particular. Basically, pthread_equal() will return > > true even if it is not the same thread. This can occur > > when one thread dies and another one starts. The second > > thread then takes on the exact identity of the the > > first thread, and pthread_equal() returns true for a > > case where it is a different thread. You may argue > > that the first thread is dead so its thread id is no > > longer valid. True, but think about how Unix would > > work if every process started up with the process > > id of the last process to exit. > > Process id's can wrap around so it can eventually happen. Yes, true. However, on Solaris and Linux, it takes a long time, for the pthread_id to wrap around, and on FreeBSD it happens in microseconds. > > This is a bug in the application; the implementation is allowed > to reuse thread id's and there are enough interfaces for an > application to tell when a thread terminates (pthread_join). I'm not sure what the POSIX specification says, if I were programming it, I would not be content with the FreeBSD current implementation especially considering that both Solaris and Linux do it "correctly". > Perhaps our use of thread id's could be changes so that they > were cached at the end of the free thread list, but cacheing > them at the front seems to highlight bad applications, so > that's a bonus ;-) This bug does not highlight bad applications because most programmers will reasonably expect that pthread_equal() will not be the same for two different threads. It took me a long time to find this problem because I just could not imagine that pthread_equal() was not "working". This problem is extremely subtle and is likely to cause unsuspecting applications long months of bizarre behavior. Fix it or not, that is your choice. Now that I know that you don't handle it as I would suspect I can code around it. From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 09:59:15 2003 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 252CB37B401 for ; Wed, 4 Jun 2003 09:59:15 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 582EC43F3F for ; Wed, 4 Jun 2003 09:59:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc01) with ESMTP id <2003060416591200100hqmlte>; Wed, 4 Jun 2003 16:59:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA02294; Wed, 4 Jun 2003 09:59:12 -0700 (PDT) Date: Wed, 4 Jun 2003 09:59:10 -0700 (PDT) From: Julian Elischer To: Kern Sibbald In-Reply-To: <1054745115.13630.517.camel@rufus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 16:59:15 -0000 On 4 Jun 2003, Kern Sibbald wrote: > > that's a bonus ;-) > > This bug does not highlight bad applications because most > programmers will reasonably expect that pthread_equal() will > not be the same for two different threads. It took me > a long time to find this problem because I just could not > imagine that pthread_equal() was not "working". > This problem is extremely subtle and is likely to cause > unsuspecting applications long months of bizarre > behavior. If IDs are recycled after a LONG time then there is still a chance that the test could go the wrong way if something held up the tester for a long enough time, so the behaviour is not "perfect", > > Fix it or not, that is your choice. Now that I know > that you don't handle it as I would suspect I can code > around it. best for now.. it is now on our radar anyhow.. thanks... > > _______________________________________________ > 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 Wed Jun 4 10:12:40 2003 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 0A08737B401 for ; Wed, 4 Jun 2003 10:12:40 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E6C543F3F for ; Wed, 4 Jun 2003 10:12:39 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h54HCY753778; Wed, 4 Jun 2003 13:12:34 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 4 Jun 2003 13:12:34 -0400 (EDT) From: Jeff Roberson To: Kern Sibbald In-Reply-To: <1054745115.13630.517.camel@rufus> Message-ID: <20030604130858.M69975-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 17:12:40 -0000 On 4 Jun 2003, Kern Sibbald wrote: > On Wed, 2003-06-04 at 17:30, Daniel Eischen wrote: > > On 4 Jun 2003, Kern Sibbald wrote: > > > Hello, > > > > > > I've run into what I consider a bug in the FreeBSD > > > implementation of pthreads and pthread_equal() in > > > particular. Basically, pthread_equal() will return > > > true even if it is not the same thread. This can occur > > > when one thread dies and another one starts. The second > > > thread then takes on the exact identity of the the > > > first thread, and pthread_equal() returns true for a > > > case where it is a different thread. You may argue > > > that the first thread is dead so its thread id is no > > > longer valid. True, but think about how Unix would > > > work if every process started up with the process > > > id of the last process to exit. > > > > Process id's can wrap around so it can eventually happen. > > Yes, true. However, on Solaris and Linux, it takes a long time, > for the pthread_id to wrap around, and on FreeBSD it happens in > microseconds. > > > > > This is a bug in the application; the implementation is allowed > > to reuse thread id's and there are enough interfaces for an > > application to tell when a thread terminates (pthread_join). > > I'm not sure what the POSIX specification says, > if I were programming it, I would not be content > with the FreeBSD current implementation especially > considering that both Solaris and Linux do it "correctly". Would you rather your application failed immediately, or in a subtle, unexpected way after many hours/weeks/months of run time? Dan says the standard allows for immediate reuse. If that is correct, then Solaris, linux, and FreeBSD all do it correctly for the only definition of correctly that matters. Simply adding an ID is problematic because the ids will wrap. Without using some deterministic notification you can't be sure that it isn't an expired thread. > > > Perhaps our use of thread id's could be changes so that they > > were cached at the end of the free thread list, but cacheing > > them at the front seems to highlight bad applications, so > > that's a bonus ;-) > > This bug does not highlight bad applications because most > programmers will reasonably expect that pthread_equal() will > not be the same for two different threads. It took me > a long time to find this problem because I just could not > imagine that pthread_equal() was not "working". > This problem is extremely subtle and is likely to cause > unsuspecting applications long months of bizarre > behavior. > > Fix it or not, that is your choice. Now that I know > that you don't handle it as I would suspect I can code > around it. > > _______________________________________________ > 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 Wed Jun 4 11:35:35 2003 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 8A66637B401 for ; Wed, 4 Jun 2003 11:35:35 -0700 (PDT) Received: from sccrmhc12.attbi.com (sccrmhc12.attbi.com [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC49343F75 for ; Wed, 4 Jun 2003 11:35:34 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.232.168.4]) by attbi.com (sccrmhc12) with ESMTP id <20030604183533012003u0vde>; Wed, 4 Jun 2003 18:35:34 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA02987; Wed, 4 Jun 2003 11:35:32 -0700 (PDT) Date: Wed, 4 Jun 2003 11:35:31 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030604130858.M69975-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kern Sibbald cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 18:35:35 -0000 On Wed, 4 Jun 2003, Jeff Roberson wrote: > On 4 Jun 2003, Kern Sibbald wrote: > > > > > I'm not sure what the POSIX specification says, > > if I were programming it, I would not be content > > with the FreeBSD current implementation especially > > considering that both Solaris and Linux do it "correctly". > > Would you rather your application failed immediately, or in a subtle, > unexpected way after many hours/weeks/months of run time? Dan says the > standard allows for immediate reuse. If that is correct, then Solaris, > linux, and FreeBSD all do it correctly for the only definition of > correctly that matters. > > Simply adding an ID is problematic because the ids will wrap. Without > using some deterministic notification you can't be sure that it isn't an > expired thread. I will quote from "Programming with Posix threads" by David R Butenhof.. He is one o fthe main authors of the Posix threads standard so I tend to treat this book as a guide.. "Once a thread is recycled, the thread's ID (pthread_t) is no longer valid. You cannot join with the thread, canel it, or anything else. The terminated thread's ID (which may be the addess of a system data structure) may be assigned to a new thread. Instead of receiving an ESRCH failure from your call to pthread_cancel, you would instead cancel a different thread." I think that is pretty explicit as far as expected bahaviour. HAVING SAID THAT, it is not impossible that at some time in the future we may use some other pthread_t type, e.g an incrementing TID, but at this time I think we are well within the standard... Julian From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 12:46:24 2003 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 59EF837B401 for ; Wed, 4 Jun 2003 12:46:24 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id B629843F3F for ; Wed, 4 Jun 2003 12:46:22 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54JjYv15739; Wed, 4 Jun 2003 21:45:34 +0200 From: Kern Sibbald To: Julian Elischer In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1054755933.13606.549.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 21:45:33 +0200 Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 19:46:24 -0000 On Wed, 2003-06-04 at 20:35, Julian Elischer wrote: > On Wed, 4 Jun 2003, Jeff Roberson wrote: > > > On 4 Jun 2003, Kern Sibbald wrote: > > > > > > > > I'm not sure what the POSIX specification says, > > > if I were programming it, I would not be content > > > with the FreeBSD current implementation especially > > > considering that both Solaris and Linux do it "correctly". > > > > Would you rather your application failed immediately, or in a subtle, > > unexpected way after many hours/weeks/months of run time? Dan says the > > standard allows for immediate reuse. If that is correct, then Solaris, > > linux, and FreeBSD all do it correctly for the only definition of > > correctly that matters. > > > > Simply adding an ID is problematic because the ids will wrap. Without > > using some deterministic notification you can't be sure that it isn't an > > expired thread. > > > I will quote from "Programming with Posix threads" > by David R Butenhof.. > He is one o fthe main authors of the Posix threads standard so > I tend to treat this book as a guide.. > > "Once a thread is recycled, the thread's ID (pthread_t) is no longer > valid. You cannot join with the thread, canel it, or anything else. The > terminated thread's ID (which may be the addess of a system data > structure) may be assigned to a new thread. Instead of receiving an > ESRCH failure from your call to pthread_cancel, you would instead cancel > a different thread." > > I think that is pretty explicit as far as expected bahaviour. > > HAVING SAID THAT, it is not impossible that at some time in the future > we may use some other pthread_t type, e.g an incrementing TID, > but at this time I think we are well within the standard... > > > Julian > Nice quote. I've already headed the warning. Sorry for bothering you. From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 13:15:24 2003 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 0927037B401 for ; Wed, 4 Jun 2003 13:15:24 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75B7B43F75 for ; Wed, 4 Jun 2003 13:15:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc51) with ESMTP id <200306042015230510025bqfe>; Wed, 4 Jun 2003 20:15:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA03645; Wed, 4 Jun 2003 13:15:22 -0700 (PDT) Date: Wed, 4 Jun 2003 13:15:21 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kern Sibbald cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 20:15:24 -0000 in fact The first paragraph of: http://www.opengroup.org/onlinepubs/007904975/toc.htm States this.. On Wed, 4 Jun 2003, Julian Elischer wrote: > > > On Wed, 4 Jun 2003, Jeff Roberson wrote: > > > On 4 Jun 2003, Kern Sibbald wrote: > > > > > > > > I'm not sure what the POSIX specification says, > > > if I were programming it, I would not be content > > > with the FreeBSD current implementation especially > > > considering that both Solaris and Linux do it "correctly". > > > > Would you rather your application failed immediately, or in a subtle, > > unexpected way after many hours/weeks/months of run time? Dan says the > > standard allows for immediate reuse. If that is correct, then Solaris, > > linux, and FreeBSD all do it correctly for the only definition of > > correctly that matters. > > > > Simply adding an ID is problematic because the ids will wrap. Without > > using some deterministic notification you can't be sure that it isn't an > > expired thread. > > > I will quote from "Programming with Posix threads" > by David R Butenhof.. > He is one o fthe main authors of the Posix threads standard so > I tend to treat this book as a guide.. > > "Once a thread is recycled, the thread's ID (pthread_t) is no longer > valid. You cannot join with the thread, canel it, or anything else. The > terminated thread's ID (which may be the addess of a system data > structure) may be assigned to a new thread. Instead of receiving an > ESRCH failure from your call to pthread_cancel, you would instead cancel > a different thread." > > I think that is pretty explicit as far as expected bahaviour. > > HAVING SAID THAT, it is not impossible that at some time in the future > we may use some other pthread_t type, e.g an incrementing TID, > but at this time I think we are well within the standard... > > > Julian > > > _______________________________________________ > 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 Wed Jun 4 13:17:49 2003 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 C312337B401 for ; Wed, 4 Jun 2003 13:17:49 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1799543FAF for ; Wed, 4 Jun 2003 13:17:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc51) with ESMTP id <200306042017480510025f0ue>; Wed, 4 Jun 2003 20:17:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA03653; Wed, 4 Jun 2003 13:17:48 -0700 (PDT) Date: Wed, 4 Jun 2003 13:17:48 -0700 (PDT) From: Julian Elischer To: Kern Sibbald In-Reply-To: <1054755933.13606.549.camel@rufus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 20:17:50 -0000 On 4 Jun 2003, Kern Sibbald wrote: > Nice quote. I've already headed the warning. Sorry for bothering you. No problems.. made me think which is always a pleasure with a 5 day old baby :-) From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 13:20:48 2003 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 3CC4437B401 for ; Wed, 4 Jun 2003 13:20:48 -0700 (PDT) Received: from sccrmhc12.attbi.com (sccrmhc12.attbi.com [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86EF143F93 for ; Wed, 4 Jun 2003 13:20:47 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.232.168.4]) by attbi.com (sccrmhc12) with ESMTP id <20030604202046012003v6s2e>; Wed, 4 Jun 2003 20:20:46 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA03691; Wed, 4 Jun 2003 13:20:45 -0700 (PDT) Date: Wed, 4 Jun 2003 13:20:43 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kern Sibbald cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 20:20:48 -0000 On Wed, 4 Jun 2003, Julian Elischer wrote: > in fact The first paragraph of: uh, not the first parageaph.. the paragraph marked "Thread IDs" (didn't notice the page was scrolled up a bit) > > http://www.opengroup.org/onlinepubs/007904975/toc.htm > > States this.. > > > On Wed, 4 Jun 2003, Julian Elischer wrote: > > > > > > > On Wed, 4 Jun 2003, Jeff Roberson wrote: > > > > > On 4 Jun 2003, Kern Sibbald wrote: > > > > > > > > > > > I'm not sure what the POSIX specification says, > > > > if I were programming it, I would not be content > > > > with the FreeBSD current implementation especially > > > > considering that both Solaris and Linux do it "correctly". > > > > > > Would you rather your application failed immediately, or in a subtle, > > > unexpected way after many hours/weeks/months of run time? Dan says the > > > standard allows for immediate reuse. If that is correct, then Solaris, > > > linux, and FreeBSD all do it correctly for the only definition of > > > correctly that matters. > > > > > > Simply adding an ID is problematic because the ids will wrap. Without > > > using some deterministic notification you can't be sure that it isn't an > > > expired thread. > > > > > > I will quote from "Programming with Posix threads" > > by David R Butenhof.. > > He is one o fthe main authors of the Posix threads standard so > > I tend to treat this book as a guide.. > > > > "Once a thread is recycled, the thread's ID (pthread_t) is no longer > > valid. You cannot join with the thread, canel it, or anything else. The > > terminated thread's ID (which may be the addess of a system data > > structure) may be assigned to a new thread. Instead of receiving an > > ESRCH failure from your call to pthread_cancel, you would instead cancel > > a different thread." > > > > I think that is pretty explicit as far as expected bahaviour. > > > > HAVING SAID THAT, it is not impossible that at some time in the future > > we may use some other pthread_t type, e.g an incrementing TID, > > but at this time I think we are well within the standard... > > > > > > Julian > > > > > > _______________________________________________ > > 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-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 Wed Jun 4 14:08:14 2003 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 69B7E37B401 for ; Wed, 4 Jun 2003 14:08:14 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9902043FBD for ; Wed, 4 Jun 2003 14:08:10 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54L7Pv16017; Wed, 4 Jun 2003 23:07:25 +0200 From: Kern Sibbald To: Julian Elischer In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1054760845.13630.568.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 23:07:25 +0200 Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 21:08:14 -0000 I like that word "robustness" :-) On Wed, 2003-06-04 at 22:20, Julian Elischer wrote: > On Wed, 4 Jun 2003, Julian Elischer wrote: > > > in fact The first paragraph of: > > uh, not the first parageaph.. the paragraph marked "Thread IDs" > (didn't notice the page was scrolled up a bit) > > > > > http://www.opengroup.org/onlinepubs/007904975/toc.htm > > > > States this.. > > > > > > On Wed, 4 Jun 2003, Julian Elischer wrote: > > > > > > > > > > > On Wed, 4 Jun 2003, Jeff Roberson wrote: > > > > > > > On 4 Jun 2003, Kern Sibbald wrote: > > > > > > > > > > > > > > I'm not sure what the POSIX specification says, > > > > > if I were programming it, I would not be content > > > > > with the FreeBSD current implementation especially > > > > > considering that both Solaris and Linux do it "correctly". > > > > > > > > Would you rather your application failed immediately, or in a subtle, > > > > unexpected way after many hours/weeks/months of run time? Dan says the > > > > standard allows for immediate reuse. If that is correct, then Solaris, > > > > linux, and FreeBSD all do it correctly for the only definition of > > > > correctly that matters. > > > > > > > > Simply adding an ID is problematic because the ids will wrap. Without > > > > using some deterministic notification you can't be sure that it isn't an > > > > expired thread. > > > > > > > > > I will quote from "Programming with Posix threads" > > > by David R Butenhof.. > > > He is one o fthe main authors of the Posix threads standard so > > > I tend to treat this book as a guide.. > > > > > > "Once a thread is recycled, the thread's ID (pthread_t) is no longer > > > valid. You cannot join with the thread, canel it, or anything else. The > > > terminated thread's ID (which may be the addess of a system data > > > structure) may be assigned to a new thread. Instead of receiving an > > > ESRCH failure from your call to pthread_cancel, you would instead cancel > > > a different thread." > > > > > > I think that is pretty explicit as far as expected bahaviour. > > > > > > HAVING SAID THAT, it is not impossible that at some time in the future > > > we may use some other pthread_t type, e.g an incrementing TID, > > > but at this time I think we are well within the standard... > > > > > > > > > Julian > > > > > > > > > _______________________________________________ > > > 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-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 Wed Jun 4 14:16:01 2003 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 493B837B401 for ; Wed, 4 Jun 2003 14:16:01 -0700 (PDT) Received: from rwcrmhc12.attbi.com (rwcrmhc12.attbi.com [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4EFF43F3F for ; Wed, 4 Jun 2003 14:16:00 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.232.168.4]) by attbi.com (rwcrmhc12) with ESMTP id <20030604211600014003ae0ne>; Wed, 4 Jun 2003 21:16:00 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA04107; Wed, 4 Jun 2003 14:15:59 -0700 (PDT) Date: Wed, 4 Jun 2003 14:15:58 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kern Sibbald cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 21:16:01 -0000 Sigh.. I might as well get the URL correct... http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html#tag_02_09_02 From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 14:25:34 2003 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 C512037B401 for ; Wed, 4 Jun 2003 14:25:34 -0700 (PDT) Received: from out014.verizon.net (out014pub.verizon.net [206.46.170.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0201343F75 for ; Wed, 4 Jun 2003 14:25:34 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.93.237]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030604170243.RLQF12592.out001.verizon.net@kokeb.ambesa.net>; Wed, 4 Jun 2003 12:02:43 -0500 Date: Wed, 4 Jun 2003 13:02:42 -0400 From: Mike Makonnen To: Kern Sibbald In-Reply-To: <1054745115.13630.517.camel@rufus> References: <1054745115.13630.517.camel@rufus> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [138.88.93.237] at Wed, 4 Jun 2003 12:02:43 -0500 Message-Id: <20030604170243.RLQF12592.out001.verizon.net@kokeb.ambesa.net> cc: eischen@pcnet.com cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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, 04 Jun 2003 21:25:35 -0000 On 04 Jun 2003 18:45:15 +0200 Kern Sibbald wrote: > > > > Process id's can wrap around so it can eventually happen. > > Yes, true. However, on Solaris and Linux, it takes a long time, > for the pthread_id to wrap around, and on FreeBSD it happens in > microseconds. This is a very specious arguement since you are relying non-deterministic behaviour in the other two implementations. They all "wrap around" eventually, and a correctly implemented application will not rely on the length time before it occurs. > This bug does not highlight bad applications because most > programmers will reasonably expect that pthread_equal() will > not be the same for two different threads. It took me > a long time to find this problem because I just could not > imagine that pthread_equal() was not "working". > This problem is extremely subtle and is likely to cause > unsuspecting applications long months of bizarre > behavior. FreeBSD's libc_r behaviour is just as correct as the other two implementations. You are relying on a non-portable feature of those implementations. In fact, I am sure you will find this out when whatever Linux distro you are using begins to use Red Hat's NPTL (Native Posix Threading Library), which does use pointers as thread IDs. As I have already quoted to you in private mail: >From IEEE Std 1003.1, 2003 Edition Begin --------- The pthread_equal() function shall return a non-zero value if t1 and t2 are equal; otherwise, zero shall be returned. If either t1 or t2 are not valid thread IDs, the behavior is undefined. End --------- The thread ID from the first thread is invalid since that thread no longer exists. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 16:53:44 2003 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 84ADD37B401 for ; Wed, 4 Jun 2003 16:53:44 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mx1.FreeBSD.org (Postfix) with SMTP id 974F143F75 for ; Wed, 4 Jun 2003 16:53:43 -0700 (PDT) (envelope-from kaeru@pd.jaring.my) Received: from unknown (HELO ?219.95.19.171?) (khairil?yusof@219.95.19.171 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 4 Jun 2003 23:53:42 -0000 From: Khairil Yusof To: threads@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AZO6pIJm2to7quRr5Zd4" Organization: Message-Id: <1054770782.765.10.camel@daemon.home.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Jun 2003 07:53:04 +0800 Subject: Guide for KSE testers? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kaeru@pd.jaring.my List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 23:53:44 -0000 --=-AZO6pIJm2to7quRr5Zd4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable With libmap.conf and kse much more stable now than before, I can finally test it out running day to day apps. I don't however have much info on how to get debugging information that would help the KSE team. Right now, there is a system lockup on my dual PIII system every few hours (much better than a few seconds a few weeks back). How do I go about getting a stacktrace or something else, that could help the KSE team? Just pointers to docs/faqs would be fine. At least these are working relatively stable right now. (I'm not sure yet, what is causing the lockups) evolution evolution-mail evolution-addressbook nautilus metacity mozilla-firebird gkrellm2 gnome-terminal gnome-panel openoffice Keep up the great work.. KSE has made a big improvement in speed and response time for evolution-mail. -- "Optimized, readable, on time; Pick any two."=20 FreeBSD 5.1-CURRENT i386=20 7:43AM up 11 mins, 1 user, load averages: 0.12, 0.23, 0.15 --=-AZO6pIJm2to7quRr5Zd4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA+3oZeDAqnLW/+/X8RAp/sAKDFFDhn7f8rrqwMgqw0JAlIUjX+CgCg44Im ZG5Bzx13JjQTft/qs7/vqyY= =UTRP -----END PGP SIGNATURE----- --=-AZO6pIJm2to7quRr5Zd4-- From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 17:12:00 2003 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 362EF37B404; Wed, 4 Jun 2003 17:12:00 -0700 (PDT) Received: from lakemtao07.cox.net (lakemtao07.cox.net [68.1.17.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A25D43F75; Wed, 4 Jun 2003 17:11:59 -0700 (PDT) (envelope-from mezz7@cox.net) Received: from sysinfo.mezzweb.com ([68.103.37.247]) by lakemtao07.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030605001159.UXRS4514.lakemtao07.cox.net@sysinfo.mezzweb.com>; Wed, 4 Jun 2003 20:11:59 -0400 Date: Wed, 04 Jun 2003 18:57:39 -0500 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=utf-8; format=flowed From: Jeremy Messenger MIME-Version: 1.0 Message-ID: User-Agent: Opera7.11/Linux M2 build 406 cc: gnome@freebsd.org Subject: libthr or libgthread (devel/glib20) bug? 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: Thu, 05 Jun 2003 00:12:00 -0000 Any apps that are depending on libgthread-2.0.so.200 always will crash if it's linking to libthr (using libmap.conf). My previous email about gst- register, it will not crash anymore if I set libgthread links to libc_r instead libthr. All ports that I have installed have been compiled with the debug (-g). Anyway, here's gdb info of ggv: =============================== % gdb ggv (gdb) r Starting program: /usr/X11R6/bin/ggv GThread-ERROR **: file gthread-posix.c: line 135 (): error 'Invalid argument' during 'pthread_getschedparam (pthread_self(), &policy, &sched)' aborting... Program received signal SIGABRT, Aborted. 0x28ab3313 in kill () at {standard input}:15 15 {standard input}: No such file or directory. in {standard input} Current language: auto; currently asm (gdb) bt #0 0x28ab3313 in kill () at {standard input}:15 #1 0x28b1eecc in abort () at /usr/src/lib/libc/stdlib/abort.c:72 #2 0x288824fb in g_logv (log_domain=0x288571c1 "GThread", log_level=G_LOG_LEVEL_ERROR, format=0x0, args1=0x0) at gmessages.c:508 #3 0x288825c4 in g_log (log_domain=0x0, log_level=0, format=0x0) at gmessages.c:527 #4 0x2885542e in g_thread_impl_init () at gthread-posix.c:135 #5 0x28856692 in g_thread_init (init=0x0) at gthread-impl.c:330 #6 0x282b382b in bonobo_activation_pre_args_parse (program=0x0, mod_info=0x0) at gnome-init.c:117 #7 0x282af903 in gnome_program_preinit (program=0x8057af0, app_id=0x8057be4 "", app_version=0x0, argc=1, argv=0xbfbffbc4) at gnome-program.c:1322 #8 0x282b0698 in gnome_program_initv (type=134595648, app_id=0x0, app_version=0x0, module_info=0x8057af0, argc=1, argv=0xbfbffbc4, first_property_name=0x0, args=0x0) at gnome-program.c:1871 #9 0x282b031a in gnome_program_init ( app_id=0x2f6 , app_version=0x2f6 , module_info=0x2f6, argc=758, argv=0x2f6, first_property_name=0x2f6 ) at gnome-program.c:1679 #10 0x0804f9e7 in main (argc=1, argv=0xbfbffbc4) at main.c:202 ---Type to continue, or q to quit--- #11 0x0804c979 in _start () =============================== Here's gthread-posix.c source codes look like.. I don't know if it helps, but at least I am trying.. 100 to 146 line: =============================== #if defined (POSIX_MIN_PRIORITY) && defined (POSIX_MAX_PRIORITY) # define HAVE_PRIORITIES 1 static gint priority_normal_value; # ifdef __FreeBSD__ /* FreeBSD threads use different priority values from the POSIX_ * defines so we just set them here. The corresponding macros * PTHREAD_MIN_PRIORITY and PTHREAD_MAX_PRIORITY are implied to be * exported by the docs, but they aren't. */ # define PRIORITY_LOW_VALUE 0 # define PRIORITY_URGENT_VALUE 31 # else /* !__FreeBSD__ */ # define PRIORITY_LOW_VALUE POSIX_MIN_PRIORITY # define PRIORITY_URGENT_VALUE POSIX_MAX_PRIORITY # endif /* !__FreeBSD__ */ # define PRIORITY_NORMAL_VALUE priority_normal_value #endif /* POSIX_MIN_PRIORITY && POSIX_MAX_PRIORITY */ static gulong g_thread_min_stack_size = 0; #define G_MUTEX_SIZE (sizeof (pthread_mutex_t)) #if defined(_SC_THREAD_STACK_MIN) || defined (HAVE_PRIORITIES) #define HAVE_G_THREAD_IMPL_INIT static void g_thread_impl_init() { #ifdef _SC_THREAD_STACK_MIN g_thread_min_stack_size = MAX (sysconf (_SC_THREAD_STACK_MIN), 0); #endif /* _SC_THREAD_STACK_MIN */ #ifdef HAVE_PRIORITIES # ifdef G_THREADS_IMPL_POSIX { struct sched_param sched; int policy; posix_check_cmd (pthread_getschedparam (pthread_self(), &policy, &sched)); <-- 135 line priority_normal_value = sched.sched_priority; } # else /* G_THREADS_IMPL_DCE */ posix_check_cmd (priority_normal_value = pthread_getprio (*(pthread_t*)thread, g_thread_priority_map [priority])); # endif #endif /* HAVE_PRIORITIES */ } #endif /* _SC_THREAD_STACK_MIN || HAVE_PRIORITIES */ =============================== CVSup'ed around 30 - 45 minutes ago and buildworld/recompile kernel.. =============================== # uname -a FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 4 18:30:22 CDT 2003 mezz@personal.mezzweb.com:/usr/obj/usr/src/sys/BSDRULZ i386 =============================== Cheers, Mezz -- bsdforums.org 's moderator, mezz. From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 17:12:24 2003 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 5A60937B401 for ; Wed, 4 Jun 2003 17:12:24 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id A30F343F85 for ; Wed, 4 Jun 2003 17:12:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc01) with ESMTP id <2003060500122200100hsk8ue>; Thu, 5 Jun 2003 00:12:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA05248; Wed, 4 Jun 2003 17:12:21 -0700 (PDT) Date: Wed, 4 Jun 2003 17:12:20 -0700 (PDT) From: Julian Elischer To: Khairil Yusof In-Reply-To: <1054770782.765.10.camel@daemon.home.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Guide for KSE testers? 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: Thu, 05 Jun 2003 00:12:24 -0000 Hi and thanks for trying it.. There are several things to keep in mind when debugging KSE. Firstly, the action is spread between the kernel and the library. Secondly, Only threads that are either running, or waiting on a kernel resource are visible to the kernel. If you have a "lockup" it is first important to distiguish between a program lockup and a system lockup. (you'd be surprised how many people don't give that information..) For a system problem we need to check the scope of the lockup.. 1/ can you ping the system? 2/ if X is not active, can you swith to other virtual consoles? 2A/ if yes, do you still get a 'password' prompt at the new console if you enter 'root' 3/ does work? If you can get to the kernel debugger with , what does 'ps' show for that process? depending on the answers we'll decide where to go next :-) On 5 Jun 2003, Khairil Yusof wrote: > With libmap.conf and kse much more stable now than before, I can finally > test it out running day to day apps. > > I don't however have much info on how to get debugging information that > would help the KSE team. > > Right now, there is a system lockup on my dual PIII system every few > hours (much better than a few seconds a few weeks back). > > How do I go about getting a stacktrace or something else, that could > help the KSE team? > > Just pointers to docs/faqs would be fine. > > At least these are working relatively stable right now. (I'm not sure > yet, what is causing the lockups) > > evolution > evolution-mail > evolution-addressbook > nautilus > metacity > mozilla-firebird > gkrellm2 > gnome-terminal > gnome-panel > openoffice That's pretty impressive.. As part of the debugging it is also probably worth seeing if you get lockups using the N:N threads (libthr) option. > > Keep up the great work.. KSE has made a big improvement in speed and > response time for evolution-mail. > > -- From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 19:57:29 2003 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 DE45837B401 for ; Wed, 4 Jun 2003 19:57:29 -0700 (PDT) Received: from lakemtao05.cox.net (lakemtao05.cox.net [68.1.17.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0697143FA3 for ; Wed, 4 Jun 2003 19:57:29 -0700 (PDT) (envelope-from mezz7@cox.net) Received: from sysinfo.mezzweb.com ([68.103.37.247]) by lakemtao05.cox.net ESMTP <20030605025728.RIRL28938.lakemtao05.cox.net@sysinfo.mezzweb.com>; Wed, 4 Jun 2003 22:57:28 -0400 Date: Wed, 04 Jun 2003 21:43:09 -0500 To: Julian Elischer Content-Type: text/plain; charset=utf-8; format=flowed References: From: Jeremy Messenger MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera7.11/Linux M2 build 406 cc: freebsd-threads@freebsd.org Subject: Re: libthr or libgthread (devel/glib20) bug? 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: Thu, 05 Jun 2003 02:57:30 -0000 On Wed, 4 Jun 2003 17:14:22 -0700 (PDT), Julian Elischer wrote: > You may have said so already, but what happens with libkse? What do you mean by I might have already said so? :-) Anyway, I forgot to input about libkse.. It doesn't crash with libkse, which it will if it's with libthr... ggv and gst-register work perfect with libkse. Cheers, Mezz > On Wed, 4 Jun 2003, Jeremy Messenger wrote: > >> Any apps that are depending on libgthread-2.0.so.200 always will crash >> if it's linking to libthr (using libmap.conf). My previous email about >> gst-register, it will not crash anymore if I set libgthread links to >> libc_r instead libthr. All ports that I have installed have been >> compiled with the debug (-g). Anyway, here's gdb info of ggv: >> >> =============================== >> % gdb ggv >> (gdb) r >> Starting program: /usr/X11R6/bin/ggv >> GThread-ERROR **: file gthread-posix.c: line 135 (): error 'Invalid >> argument' during 'pthread_getschedparam (pthread_self(), &policy, >> &sched)' >> aborting... >> Program received signal SIGABRT, Aborted. >> 0x28ab3313 in kill () at {standard input}:15 >> 15 {standard input}: No such file or directory. >> in {standard input} >> Current language: auto; currently asm >> (gdb) bt >> #0 0x28ab3313 in kill () at {standard input}:15 >> #1 0x28b1eecc in abort () at /usr/src/lib/libc/stdlib/abort.c:72 >> #2 0x288824fb in g_logv (log_domain=0x288571c1 "GThread", >> log_level=G_LOG_LEVEL_ERROR, format=0x0, args1=0x0) at gmessages.c:508 >> #3 0x288825c4 in g_log (log_domain=0x0, log_level=0, format=0x0) >> at gmessages.c:527 >> #4 0x2885542e in g_thread_impl_init () at gthread-posix.c:135 >> #5 0x28856692 in g_thread_init (init=0x0) at gthread-impl.c:330 >> #6 0x282b382b in bonobo_activation_pre_args_parse (program=0x0, >> mod_info=0x0) >> at gnome-init.c:117 >> #7 0x282af903 in gnome_program_preinit (program=0x8057af0, >> app_id=0x8057be4 "", app_version=0x0, argc=1, argv=0xbfbffbc4) >> at gnome-program.c:1322 >> #8 0x282b0698 in gnome_program_initv (type=134595648, app_id=0x0, >> app_version=0x0, module_info=0x8057af0, argc=1, argv=0xbfbffbc4, >> first_property_name=0x0, args=0x0) at gnome-program.c:1871 >> #9 0x282b031a in gnome_program_init ( >> app_id=0x2f6 , >> app_version=0x2f6 , >> module_info=0x2f6, argc=758, argv=0x2f6, >> first_property_name=0x2f6 ) >> at gnome-program.c:1679 >> #10 0x0804f9e7 in main (argc=1, argv=0xbfbffbc4) at main.c:202 >> ---Type to continue, or q to quit--- >> #11 0x0804c979 in _start () >> =============================== >> >> Here's gthread-posix.c source codes look like.. I don't know if it >> helps, but at least I am trying.. >> >> 100 to 146 line: >> =============================== >> #if defined (POSIX_MIN_PRIORITY) && defined (POSIX_MAX_PRIORITY) >> # define HAVE_PRIORITIES 1 >> static gint priority_normal_value; >> # ifdef __FreeBSD__ >> /* FreeBSD threads use different priority values from the POSIX_ >> * defines so we just set them here. The corresponding macros >> * PTHREAD_MIN_PRIORITY and PTHREAD_MAX_PRIORITY are implied to be >> * exported by the docs, but they aren't. >> */ >> # define PRIORITY_LOW_VALUE 0 >> # define PRIORITY_URGENT_VALUE 31 >> # else /* !__FreeBSD__ */ >> # define PRIORITY_LOW_VALUE POSIX_MIN_PRIORITY >> # define PRIORITY_URGENT_VALUE POSIX_MAX_PRIORITY >> # endif /* !__FreeBSD__ */ >> # define PRIORITY_NORMAL_VALUE priority_normal_value >> #endif /* POSIX_MIN_PRIORITY && POSIX_MAX_PRIORITY */ >> >> static gulong g_thread_min_stack_size = 0; >> #define G_MUTEX_SIZE (sizeof (pthread_mutex_t)) >> #if defined(_SC_THREAD_STACK_MIN) || defined (HAVE_PRIORITIES) >> #define HAVE_G_THREAD_IMPL_INIT >> static void >> g_thread_impl_init() >> { >> #ifdef _SC_THREAD_STACK_MIN >> g_thread_min_stack_size = MAX (sysconf (_SC_THREAD_STACK_MIN), 0); >> #endif /* _SC_THREAD_STACK_MIN */ >> #ifdef HAVE_PRIORITIES >> # ifdef G_THREADS_IMPL_POSIX >> { >> struct sched_param sched; >> int policy; >> posix_check_cmd (pthread_getschedparam (pthread_self(), &policy, &sched)) >> >> >> ; <-- 135 line >> priority_normal_value = sched.sched_priority; >> } >> # else /* G_THREADS_IMPL_DCE */ >> posix_check_cmd (priority_normal_value = >> pthread_getprio (*(pthread_t*)thread, >> g_thread_priority_map [priority])); >> # endif >> #endif /* HAVE_PRIORITIES */ >> } >> #endif /* _SC_THREAD_STACK_MIN || HAVE_PRIORITIES */ >> =============================== >> >> CVSup'ed around 30 - 45 minutes ago and buildworld/recompile kernel.. >> =============================== >> # uname -a >> FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun >> 4 18:30:22 CDT 2003 >> mezz@personal.mezzweb.com:/usr/obj/usr/src/sys/BSDRULZ i386 >> =============================== >> >> Cheers, >> Mezz >> >> >> -- bsdforums.org 's moderator, mezz. >> _______________________________________________ >> 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" >> > > -- bsdforums.org 's moderator, mezz. From owner-freebsd-threads@FreeBSD.ORG Thu Jun 5 01:45:23 2003 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 64CA337B401; Thu, 5 Jun 2003 01:45:23 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BADF43F75; Thu, 5 Jun 2003 01:45:20 -0700 (PDT) (envelope-from ml@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h55BjrU6076197; Thu, 5 Jun 2003 11:45:53 GMT Received: (from ml@localhost) by phantom.cris.net (8.12.6/8.12.2) id h558qM5I060453; Thu, 5 Jun 2003 11:52:22 +0300 (EEST) (envelope-from ml) Date: Thu, 5 Jun 2003 11:52:22 +0300 From: Alexey Zelkin To: Daniel Eischen Message-ID: <20030605115222.B60385@phantom.cris.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@pcnet.com on Tue, Jun 03, 2003 at 05:48:15AM -0400 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: freebsd-threads@freebsd.org cc: freebsd-java@freebsd.org Subject: Re: Fwd: Re: Native JDK with libthr/libkse 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: Thu, 05 Jun 2003 08:45:23 -0000 hi, On Tue, Jun 03, 2003 at 05:48:15AM -0400, Daniel Eischen wrote: > I was more interested in the statement that "jdk is only guaranteed > to work with libc_r" that one of the Java developers posted. I It only means that I can guarantee correctly working product in environment there're it was tested (i.e. at user threads only level). Don't get me wrong -- I'll be happy to try libthr and libpthread as soon as I'll be able to do it. Local problems here prevents me from complete cvsup right now :-( Also I have to make complete pass of TCK tests (at least VM tests -- more than 8000 testsets) before saying anything. > took it to mean that the implementation of our jdk is geared > towards libc_r (perhaps knowing internal stuff about how libc_r > works). I don't want anything like that to stop us, and we > can add some common APIs to the threads libraries if needed > to support it. I have spent a lot of time to get rid libc_r internals usage in jdk14. pthread_attr_get_np() was a conclusion and allowed me to switch from API to ABI compat mode. From owner-freebsd-threads@FreeBSD.ORG Thu Jun 5 04:42:44 2003 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 6FDCC37B401 for ; Thu, 5 Jun 2003 04:42:44 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0593B43FDD for ; Thu, 5 Jun 2003 04:42:44 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmr7.dialup.mindspring.com ([165.247.219.103] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Nt8g-0006E6-00; Thu, 05 Jun 2003 04:42:39 -0700 Message-ID: <3EDF2C6B.7A8E5C21@mindspring.com> Date: Thu, 05 Jun 2003 04:41:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4394c788ad2786350066fea3bf2740a44387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: Kern Sibbald cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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: Thu, 05 Jun 2003 11:42:44 -0000 Daniel Eischen wrote: > Process id's can wrap around so it can eventually happen. > > This is a bug in the application; the implementation is allowed > to reuse thread id's and there are enough interfaces for an > application to tell when a thread terminates (pthread_join). > > Perhaps our use of thread id's could be changes so that they > were cached at the end of the free thread list, but cacheing > them at the front seems to highlight bad applications, so > that's a bonus ;-) So's not explicitly protecting dlopen(), and so's not forcing rescheduling of the thread that was running at preemption time, when returning from an involuntary preemption. ;^). If you're willing to hack around these two, why not the thread ID as well? 8-) 8-). -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jun 5 05:02:44 2003 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 7BD6F37B401 for ; Thu, 5 Jun 2003 05:02:44 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCD4543FB1 for ; Thu, 5 Jun 2003 05:02:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmr7.dialup.mindspring.com ([165.247.219.103] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19NtRv-000180-00; Thu, 05 Jun 2003 05:02:31 -0700 Message-ID: <3EDF3113.A785CEA4@mindspring.com> Date: Thu, 05 Jun 2003 05:01:23 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kern Sibbald References: <1054745115.13630.517.camel@rufus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44c2e105390c21475c5a1d114f98fa148350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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: Thu, 05 Jun 2003 12:02:44 -0000 Kern Sibbald wrote: > > This is a bug in the application; the implementation is allowed > > to reuse thread id's and there are enough interfaces for an > > application to tell when a thread terminates (pthread_join). > > I'm not sure what the POSIX specification says, > if I were programming it, I would not be content > with the FreeBSD current implementation especially > considering that both Solaris and Linux do it "correctly". For some number of intervening threads less than 30,000. > This bug does not highlight bad applications because most > programmers will reasonably expect that pthread_equal() will > not be the same for two different threads. It took me > a long time to find this problem because I just could not > imagine that pthread_equal() was not "working". This is a statistical expectation, at best. Technically, you should avoid anything that makes only statistical guarantees. For example, it's possible to run without memory protection through address space separation: what you do is just make sure your physical memory size statistically small compared to your available address space; for example, say I have 4G of physical RAM, and I have a 64 bit processor. The chance of me "guessing" a valid page without faulting is 1:2^32, so I don't "need" to enforce address space separation, and I avoid all sorts of TLB shootdowns and protection domain crossing, etc. Comparatively, your protection against a failure with the pthread_equal() call on the systems you are using as an example of "correct" is less than 1:2^15. This example is particularly apt, since threads share a process address space. > This problem is extremely subtle and is likely to cause > unsuspecting applications long months of bizarre > behavior. Yes. This is the real problem: application expectations. As I implied in my previous message, you have to draw a firm line between "application expectations" and "strict conformance of applications to the standard". There are already several compromises in FreeBSD's implementations for applications expectations; "in for a penny, in for a pound". > Fix it or not, that is your choice. Now that I know > that you don't handle it as I would suspect I can code > around it. IMO, a request to "fix" this (provide an implementation kludge that will keep applications happy) is a lot more reasonable than locking up ld.so in contravention of the SUSv2 Chapter 12. As you point out, all it would take is the addition of a generation count to the pthreads structures; if they are type-stable enough to reuse the same address, then a generation count is not unreasonable, and if they aren't type-stable enough, then it's not a problem in the first place (it's just your particular application has degenerate behaviour in memory reuse). -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jun 5 05:38:17 2003 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 304DA37B401 for ; Thu, 5 Jun 2003 05:38:17 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8696443F3F for ; Thu, 5 Jun 2003 05:38:15 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h55Cc9v18695; Thu, 5 Jun 2003 14:38:10 +0200 From: Kern Sibbald To: Terry Lambert In-Reply-To: <3EDF3113.A785CEA4@mindspring.com> References: <3EDF3113.A785CEA4@mindspring.com> Content-Type: text/plain Organization: Message-Id: <1054816689.13630.713.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Jun 2003 14:38:09 +0200 Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" 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: Thu, 05 Jun 2003 12:38:17 -0000 Hello, Yes, it is evident that no matter what one does at some point the thread id will wrap around -- unless you use a 64 bit counter. My program wouldn't have had any problems if it wrapped around some "reasonable" time later, but in fact, it "wrapped" on the very next thread. I can see that I was wrong to classify the FreeBSD as a bug, but it would be valid to say that the FreeBSD implementation is not as "robust" as the spec would permit (or advise). Please see: http://www.opengroup.org/onlinepubs/007904975/toc.htm under "Rationale", the view they express is what I consider a preferred or more robust implementation "additional flexibility and robustness" ... I don't quite understand your point about locking up ld.so, probably because I am not subscribed to the list, and it isn't worth your time to explain it, but I certainly would not advocate any change that destabilizes something. On the other hand, a little loss of performance is a good thing if it helps applications run better and/or detect their bugs. As I said, I leave it to you guys to decide what to do or not to do. I know what I did wrong and have long ago fixed it Best regards, Kern On Thu, 2003-06-05 at 14:01, Terry Lambert wrote: > Kern Sibbald wrote: > > > This is a bug in the application; the implementation is allowed > > > to reuse thread id's and there are enough interfaces for an > > > application to tell when a thread terminates (pthread_join). > > > > I'm not sure what the POSIX specification says, > > if I were programming it, I would not be content > > with the FreeBSD current implementation especially > > considering that both Solaris and Linux do it "correctly". > > For some number of intervening threads less than 30,000. > > > > This bug does not highlight bad applications because most > > programmers will reasonably expect that pthread_equal() will > > not be the same for two different threads. It took me > > a long time to find this problem because I just could not > > imagine that pthread_equal() was not "working". > > This is a statistical expectation, at best. Technically, > you should avoid anything that makes only statistical > guarantees. > > For example, it's possible to run without memory protection > through address space separation: what you do is just make > sure your physical memory size statistically small compared > to your available address space; for example, say I have 4G > of physical RAM, and I have a 64 bit processor. The chance > of me "guessing" a valid page without faulting is 1:2^32, > so I don't "need" to enforce address space separation, and > I avoid all sorts of TLB shootdowns and protection domain > crossing, etc. > > Comparatively, your protection against a failure with the > pthread_equal() call on the systems you are using as an > example of "correct" is less than 1:2^15. > > This example is particularly apt, since threads share a > process address space. > > > > This problem is extremely subtle and is likely to cause > > unsuspecting applications long months of bizarre > > behavior. > > Yes. This is the real problem: application expectations. > > As I implied in my previous message, you have to draw a > firm line between "application expectations" and "strict > conformance of applications to the standard". There are > already several compromises in FreeBSD's implementations > for applications expectations; "in for a penny, in for a > pound". > > > > Fix it or not, that is your choice. Now that I know > > that you don't handle it as I would suspect I can code > > around it. > > IMO, a request to "fix" this (provide an implementation > kludge that will keep applications happy) is a lot more > reasonable than locking up ld.so in contravention of the > SUSv2 Chapter 12. As you point out, all it would take > is the addition of a generation count to the pthreads > structures; if they are type-stable enough to reuse the > same address, then a generation count is not unreasonable, > and if they aren't type-stable enough, then it's not a > problem in the first place (it's just your particular > application has degenerate behaviour in memory reuse). > > -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Jun 5 09:08:17 2003 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 9053E37B401 for ; Thu, 5 Jun 2003 09:08:17 -0700 (PDT) Received: from smtp101.mail.sc5.yahoo.com (smtp101.mail.sc5.yahoo.com [216.136.174.139]) by mx1.FreeBSD.org (Postfix) with SMTP id 448E043F85 for ; Thu, 5 Jun 2003 09:08:15 -0700 (PDT) (envelope-from kaeru@pd.jaring.my) Received: from unknown (HELO ?219.95.19.133?) (khairil?yusof@219.95.19.133 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jun 2003 16:08:13 -0000 From: Khairil Yusof To: Julian Elischer In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T6oCFSbj5hupbgCG/9k7" Organization: Message-Id: <1054829253.805.12.camel@daemon.home.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 06 Jun 2003 00:07:34 +0800 cc: threads@freebsd.org Subject: Re: Guide for KSE testers? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kaeru@pd.jaring.my List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2003 16:08:17 -0000 --=-T6oCFSbj5hupbgCG/9k7 Content-Type: multipart/mixed; boundary="=-h13snuEPpwjjGAdtUxNt" --=-h13snuEPpwjjGAdtUxNt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-06-05 at 08:12, Julian Elischer wrote: > For a system problem we need to check the scope of the lockup.. > 1/ can you ping the system? Nope. > 2/ if X is not active, can you swith to other virtual consoles? Nope. > 3/ does work? Nope. Basically since I sent original mail, the system was running untouched at home upgrading all ports with portupgrade for several hours. Several of the apps, that I mentioned using libkse.so were running without user imput. I then used it for about an hour (reading mail mostly with evolution using libkse.so), opening closing terminals (gnome-term using libkse).=20 While I was about to type something in the terminal, I got one of those lockups (only when using libkse). No system response as I stated above, so I'm stuck as I have no information at all what caused it. The only way out is the power button. I'm gonna get this again.. what should I do to get info for debugging? I've attached my kern.conf, and dmesg, in case there is something there that is a known problem. -- "Optimized, readable, on time; Pick any two."=20 FreeBSD 5.1-CURRENT i386=20 11:55PM up 25 mins, 1 user, load averages: 0.02, 0.07, 0.08 --=-h13snuEPpwjjGAdtUxNt Content-Disposition: attachment; filename=DAEMON Content-Type: text/plain; name=DAEMON; charset=UTF-8 Content-Transfer-Encoding: quoted-printable # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig= -config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files.=20 # If you are in doubt as to the purpose or necessity of a line, check first= =20 # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.369.2.2 2002/12/31 05:35:45 scott= l Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident DAEMON maxusers 0 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT #NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=3D10000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O #options ADAPTIVE_MUTEXES options CPU_FASTER_5X86_FPU # Faster Pentium FPU options CPU_SUSP_HLT # Allows CPU to go into suspend mode on HALT # PERFMON causes the driver for Pentium/Pentium Pro performance counters # to be compiled. See perfmon(4) for more information. # options PERFMON device isa #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # RAID controllers interfaced to the SCSI subsystem #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options! #device iir # Intel Integrated RAID #device mly # Mylex AcceleRAID/eXtremeRAID # SCSI peripherals device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device amr # AMI MegaRAID #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VESA device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges #device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. #options DEVICE_POLLING #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs= ! device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') #device bge # Broadcom BCM570xx Gigabit Ethernet # ISA Ethernet NICs. pccard nics included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of ethernet chips #device xe # Xircom pccard ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device an # Aironet 4500/4800 802.11 wireless NICs.=20 #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device urio # Diamond Rio 500 MP3 player device uscanner # Scanners device ucom #device uvisor # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=3D100 #limit verbosity options IPFIREWALL_FORWARD options IPDIVERT #divert sockets device pcm --=-h13snuEPpwjjGAdtUxNt Content-Disposition: attachment; filename=dmesg.boot Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=dmesg.boot; charset=UTF-8 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #17: Wed Jun 4 22:11:14 MYT 2003 root@daemon.home.net:/usr/obj/usr/src/sys/DAEMON Preloaded elf kernel "/boot/kernel/kernel" at 0xc05c5000. Preloaded elf module "/boot/kernel/splash_bmp.ko" at 0xc05c5244. Preloaded splash_image_data "/boot/splash.bmp" at 0xc05c52f4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05c5344. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 449234633 Hz CPU: Pentium III/Pentium III Xeon/Celeron (449.23-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x673 Stepping =3D 3 Features=3D0x383fbff real memory =3D 536858624 (511 MB) avail memory =3D 515158016 (491 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c5477 (c0005477) VESA: Matrox Graphics Inc. npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f1c90 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfd08-0xfd0b on acpi0 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 18 -> irq 2 IOAPIC #0 intpin 19 -> irq 9 agp0: mem 0xf0000000-0xf3ffffff= at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 IOAPIC #0 intpin 16 -> irq 10 pci1: at device 0.0 (no driver attached) fxp0: port 0x70c0-0x70df= mem 0xf7500000-0xf75fffff,0xefffe000-0xefffefff irq 2 at device 2.0 on pci= 0 fxp0: Ethernet address 00:60:94:eb:5f:59 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0x7400-0x74ff mem 0xf74fe00= 0-0xf74fefff irq 9 at device 3.0 on pci0 aic7895C: Ultra Wide Channel A, SCSI Id=3D7, 32/253 SCBs ahc1: port 0x7800-0x78ff mem 0xf74ff00= 0-0xf74fffff irq 9 at device 3.1 on pci0 aic7895C: Ultra Wide Channel B, SCSI Id=3D7, 32/253 SCBs isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xfff0-0xffff at device 4.1 o= n pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xff00-0xff1f irq 9 a= t device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered piix0 port 0xfe00-0xfe0f at device 4.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz fxp1: port 0x70e0-0x70ff= mem 0xf7600000-0xf76fffff,0xeffff000-0xefffffff irq 2 at device 14.0 on pc= i0 fxp1: Ethernet address 00:60:94:f0:4c:77 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: port 0x3f7,0x= 3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 pcm0: port 0x530-0x537 on acpi0 device_probe_and_attach: pcm0 attach returned 6 orm0: