From owner-freebsd-threads@FreeBSD.ORG Sun Oct 31 04:23:26 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B52316A4CF; Sun, 31 Oct 2004 04:23:26 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6D543D53; Sun, 31 Oct 2004 04:23:25 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])i9V4NJ5g410412; Sun, 31 Oct 2004 00:23:20 -0400 Message-ID: <418468B7.9060803@elischer.org> Date: Sat, 30 Oct 2004 21:23:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <41817EE4.9080302@elischer.org> <41840FB3.2020305@freebsd.org> In-Reply-To: <41840FB3.2020305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org cc: re@freebsd.org cc: David Xu cc: John Baldwin Subject: Re: MFC req for 5.x/5.3 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, 31 Oct 2004 04:23:26 -0000 Scott Long wrote: > Julian Elischer wrote: > >> >> >> Daniel Eischen wrote: >> >>> On Thu, 28 Oct 2004, Julian Elischer wrote: >>> >>> >>> >>>> David Xu wrote: >>>> >>>> >>>> >>>>> Here is the cvs log: >>>>> >>>>> Revision Changes Path >>>>> 1.58 +1 -0 src/lib/libpthread/thread/thr_create.c >>>>> 1.14 +1 -1 src/lib/libpthread/thread/thr_find_thread.c >>>>> 1.115 +27 -10 src/lib/libpthread/thread/thr_kern.c >>>>> 1.119 +15 -11 src/lib/libpthread/thread/thr_private.h >>>>> 1.81 +1 -2 src/lib/libpthread/thread/thr_sig.c >>>>> >>>> >>>> >>>> commit message was: >>>> 1. Move thread list flags into new separate member, and atomically >>>> put DEAD thread on GC list, this closes a race between pthread_join >>>> and thr_cleanup. >>>> 2. Introduce a mutex to protect tcb initialization, tls allocation and >>>> deallocation code in rtld seems no lock protection or it is broken, >>>> under stress testing, memory is corrupted. >>>> >>>> >>>> translates to: >>>> >> >> [diff removed] >> >>>> >>> >>> >>> >>> Yes, these look right. >>> >>> >>> >> > > Julian and all, > > I know that re@ approved these a few days ago, but we haven't seen any > acticity and we need to get RC2 out so that SACK can get validated and > we can turn to -RELEASE. I know it's very short notice, but I'm going > to retract this MFC approval and instead ask that you only commit it to > RELENG_5. > > Scott I only ever had permission to go to RELENG_5.. Only got to do it today as Real Life(TM) got in the way. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 1 11:02:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E993616A4D6 for ; Mon, 1 Nov 2004 11:02:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2FC443D48 for ; Mon, 1 Nov 2004 11:02:13 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iA1B2DT7094343 for ; Mon, 1 Nov 2004 11:02:13 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA1B2DiM094337 for freebsd-threads@freebsd.org; Mon, 1 Nov 2004 11:02:13 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Nov 2004 11:02:13 GMT Message-Id: <200411011102.iA1B2DiM094337@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 11:02:14 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc o [2003/05/08] threads/51949threads thread in accept cannot be cancelled s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse 8 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Nov 2 03:09:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF2916A4CE for ; Tue, 2 Nov 2004 03:09:30 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3D0C43D39 for ; Tue, 2 Nov 2004 03:09:30 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D8C24533B9; Mon, 1 Nov 2004 19:11:24 -0800 (PST) Date: Mon, 1 Nov 2004 19:11:24 -0800 From: Kris Kennaway To: threads@FreeBSD.org Message-ID: <20041102031124.GA69552@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [kris@obsecurity.org: named and KSE] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 03:09:31 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ping ----- Forwarded message from Kris Kennaway ----- Date: Sun, 24 Oct 2004 19:40:34 -0700 From: Kris Kennaway To: current@freeBSD.org Subject: named and KSE User-Agent: Mutt/1.4.2.1i This SMP 5.3-STABLE system updated yesterday acts as a resolver for a bunch of package clients. I just got this message in the logs: Oct 25 01:45:00 pointyhat named[281]: *** POKED TIMER *** This comes from contrib/bind9/lib/isc/timer.c: /* * This is a temporary (probably) hack to fix a bug on tru64 5.1 * and 5.1a. Sometimes, pthread_cond_timedwait() doesn't actually * return when the time expires, so here, we check to see if * we're 15 seconds or more behind, and if we are, we signal * the dispatcher. This isn't such a bad idea as a general purpose * watchdog, so perhaps we should just leave it in here. */ if (signal_ok && timedwait) { isc_interval_t fifteen; isc_time_t then; isc_interval_set(&fifteen, 15, 0); isc_time_add(&manager->due, &fifteen, &then); if (isc_time_compare(&then, now) < 0) { SIGNAL(&manager->wakeup); signal_ok =3D ISC_FALSE; isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, ISC_LOGMODULE_TIMER, ISC_LOG_WARNING, "*** POKED TIMER ***"); } } and suggests it could be a threading bug. Kris ----- End forwarded message ----- --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBhvrcWry0BWjoQKURAoOtAJ9jlvjxQKLVmWuaVtJCchhQqXjNpQCgwqbb yzjhFj+zSN8SZKmIxeKDZj8= =1+Be -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-threads@FreeBSD.ORG Tue Nov 2 05:14:50 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72EA516A4CE for ; Tue, 2 Nov 2004 05:14:50 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD1F43D2F for ; Tue, 2 Nov 2004 05:14:50 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA25Em7p022051; Tue, 2 Nov 2004 00:14:48 -0500 (EST) Date: Tue, 2 Nov 2004 00:14:48 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kris Kennaway In-Reply-To: <20041102031124.GA69552@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: [kris@obsecurity.org: named and KSE] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 05:14:50 -0000 On Mon, 1 Nov 2004, Kris Kennaway wrote: > Ping There's not a lot to go on by that comment. David Xu has been working on a patch to fix a race condition that may prevent loss of wakeup in pthread_cond_{timed}wait() so that may fix the problem. -- Dan Eischen > > ----- Forwarded message from Kris Kennaway ----- > > Date: Sun, 24 Oct 2004 19:40:34 -0700 > From: Kris Kennaway > To: current@freeBSD.org > Subject: named and KSE > User-Agent: Mutt/1.4.2.1i > > This SMP 5.3-STABLE system updated yesterday acts as a resolver for a > bunch of package clients. I just got this message in the logs: > > Oct 25 01:45:00 pointyhat named[281]: *** POKED TIMER *** > > This comes from contrib/bind9/lib/isc/timer.c: > > /* > * This is a temporary (probably) hack to fix a bug on tru64 5.1 > * and 5.1a. Sometimes, pthread_cond_timedwait() doesn't actually > * return when the time expires, so here, we check to see if > * we're 15 seconds or more behind, and if we are, we signal > * the dispatcher. This isn't such a bad idea as a general purpose > * watchdog, so perhaps we should just leave it in here. > */ > if (signal_ok && timedwait) { > isc_interval_t fifteen; > isc_time_t then; > > isc_interval_set(&fifteen, 15, 0); > isc_time_add(&manager->due, &fifteen, &then); > > if (isc_time_compare(&then, now) < 0) { > SIGNAL(&manager->wakeup); > signal_ok = ISC_FALSE; > isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, > ISC_LOGMODULE_TIMER, ISC_LOG_WARNING, > "*** POKED TIMER ***"); > } > } > > and suggests it could be a threading bug. > > Kris > > > > ----- End forwarded message ----- > -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Nov 2 21:11:26 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8853E16A548 for ; Tue, 2 Nov 2004 21:11:24 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 632FA43D1F for ; Tue, 2 Nov 2004 21:11:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2451 invoked from network); 2 Nov 2004 21:11:24 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Nov 2004 21:11:23 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA2LAuYU070948 for ; Tue, 2 Nov 2004 16:11:20 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: threads@FreeBSD.org Date: Tue, 2 Nov 2004 17:12:11 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200411021712.11115.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: More mono + libpthread breakage.. 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, 02 Nov 2004 21:11:26 -0000 It looks like libpthread is not calling _cond_wait_backout() when a thread gets a signal after calling thr_sched_switch() from pthread_cond_wait(). Inside of thr_sched_switch_unlocked(), it leaves a critical section and finds a pending signal, calls thr_sig_defer(). This then calls thr_sig_rundown() with a psf of NULL. thr_sig_rundown() only checks psf's state to see if it needs to call _cond_wait_backout(). In libc_r on 4.x at least the state is always saved into a psf before the equivalent thr_sig_rundown() is called, i.e. it never has a NULL psf. However, deferred signals from kse_critical_leave() are never going to back out a mutex queue or condition variable queue. This kicks in with mono because mono wants to call 'sem_post()' (which is supposed to be signal safe) from a signal handler, but sem_post() calls pthread_mutex_lock() which dies with an assertion error about already being on a syncq since _cond_wait_backout() didn't happen. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 04:36:53 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B7616A4CE for ; Wed, 3 Nov 2004 04:36:53 +0000 (GMT) Received: from hellmouth3.gatech.edu (hellmouth3.gatech.edu [130.207.165.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECB9243D39 for ; Wed, 3 Nov 2004 04:36:52 +0000 (GMT) (envelope-from gte990t@mail.gatech.edu) Received: from hellmouth3.gatech.edu (localhost [127.0.0.1]) by hellmouth3.gatech.edu (Postfix) with SMTP id 86E4E220ECE for ; Tue, 2 Nov 2004 23:36:52 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from mailprx4.gatech.edu (mailprx4.prism.gatech.edu [130.207.171.18]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (verified OK)) by hellmouth3.gatech.edu (Postfix) with ESMTP id 71B19220E8D for ; Tue, 2 Nov 2004 23:36:52 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from [192.168.0.3] (r58h96.res.gatech.edu [128.61.58.96]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (sasl: method=PLAIN, username=gte990t, sender=n/a) by mailprx4.gatech.edu (Postfix) with ESMTP id BB66A3A5EE for ; Tue, 2 Nov 2004 23:36:50 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) From: Jason Harmening Date: Tue, 2 Nov 2004 23:56:06 -0500 User-Agent: KMail/1.7 To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411022356.06257.gte990t@mail.gatech.edu> Subject: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state 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, 03 Nov 2004 04:36:53 -0000 The following message has already been posted to the freebsd-current mailing list. Please note that the unkillable process problem originally reported in 5.3-RC1 is NOT isolated to gdb/kde, and seems to occur with OpenOffice under heavy loads, especially with java running at the same time. Furthermore, 5.3-RC2 does not fix the problem. Several other people have chimed in saying they have the same problem, and I think it would be a BAD idea to release 5.3 without fixing this. I don't have the kernel expertise to directly delve into the problem, but I do have a reasonable amount of systems-level development/troubleshooting experience, so I would be more than willing to help with debugging/diagnosis if someone could point me in the right direction. Thanks, Jason Harmening ---------- Forwarded Message ---------- Subject: Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state Date: Tuesday 02 November 2004 11:45 From: Jason Harmening To: Alex Dupre Cc: freebsd-current@freebsd.org On Tuesday 02 November 2004 09:00, you wrote: > Jason Harmening wrote: > > I just upgraded to 5.3-RC2, and I'm still running into the problem where > > processes will hang in an unkillable state. In particular, this happens > > for me with OpenOffice under a heavy load. 'ps' reports the state as > > 'TL' and 'top' reports the state as STOP. Neither kill -CONT nor kill > > -KILL will work. > > Same here. With OpenOffice and Java under high load. Yes--I forgot to mention it, but my OpenOffice problems have all seemed to happen at the same time I have some instance of the JVM (native 1.4.2) running. OpenOffice will start up, reach almost the end of its splash screen, and then simply hang in an unkillable state. This has a very sinister side effect in that, when the system does its daily security run (I'm also assuming it tries to clean up useless processes), and there's such an "unkillable" process, the entire system will hang. It's not an abrupt freeze, but it's a gradual "bogging down" that ultimately requires a hard reset. The same thing happens during a shutdown/reboot with an unkillable process, but luckily the system manages to sync the disk before hanging. ------------------------------------------------------- From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 12:04:51 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DC4F16A4CE; Wed, 3 Nov 2004 12:04:51 +0000 (GMT) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CA8843D49; Wed, 3 Nov 2004 12:04:48 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.1/8.13.1) with ESMTP id iA3C4Bim022004; Wed, 3 Nov 2004 13:04:11 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <4188C93B.2010209@fer.hr> Date: Wed, 03 Nov 2004 13:04:11 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.8 (X11/20041021) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200411021712.11115.jhb@FreeBSD.org> In-Reply-To: <200411021712.11115.jhb@FreeBSD.org> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: More mono + libpthread breakage.. 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, 03 Nov 2004 12:04:51 -0000 John Baldwin wrote: > It looks like libpthread is not calling _cond_wait_backout() when a thread > gets a signal after calling thr_sched_switch() from pthread_cond_wait(). Glad to see the issue was not abandoned! I only understood a fraction of this, so is it something that could be fixed soon? (Maybe even, hopefully, for 5.3-release? :)) ) From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 14:21:01 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D86C916A4CE; Wed, 3 Nov 2004 14:21:01 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95A7F43D53; Wed, 3 Nov 2004 14:20:29 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.68.109] (HELO rogue.acs.lan) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP id 61938183; Wed, 03 Nov 2004 17:12:24 +0300 Received: by rogue.acs.lan (Postfix, from userid 1000) id 0C3BEB830; Wed, 3 Nov 2004 17:19:14 +0300 (EAT) Date: Wed, 3 Nov 2004 17:19:14 +0300 From: Mike Makonnen To: John Baldwin Message-ID: <20041103141914.GA2095@rogue.acs.lan> References: <200411021712.11115.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411021712.11115.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/6.0-CURRENT (i386) cc: threads@freebsd.org Subject: Re: More mono + libpthread breakage.. 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, 03 Nov 2004 14:21:02 -0000 On Tue, Nov 02, 2004 at 05:12:11PM -0500, John Baldwin wrote: > This kicks in with mono because mono wants to call > 'sem_post()' (which is supposed to be signal safe) from a signal handler, but > sem_post() calls pthread_mutex_lock() which dies with an assertion error > about already being on a syncq since _cond_wait_backout() didn't happen. Then the correct fix is for sem_post to disable signals around calls to pthread functions. There are *no* async-signal safe pthread functions. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 15:24:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55E1216A4CE; Wed, 3 Nov 2004 15:24:15 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B0143D3F; Wed, 3 Nov 2004 15:24:14 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA3FOAqO004496; Wed, 3 Nov 2004 10:24:11 -0500 (EST) Date: Wed, 3 Nov 2004 10:24:10 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Mike Makonnen In-Reply-To: <20041103141914.GA2095@rogue.acs.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: John Baldwin Subject: Re: More mono + libpthread breakage.. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 15:24:15 -0000 On Wed, 3 Nov 2004, Mike Makonnen wrote: > On Tue, Nov 02, 2004 at 05:12:11PM -0500, John Baldwin wrote: > > This kicks in with mono because mono wants to call > > 'sem_post()' (which is supposed to be signal safe) from a signal handler, but > > sem_post() calls pthread_mutex_lock() which dies with an assertion error > > about already being on a syncq since _cond_wait_backout() didn't happen. > > Then the correct fix is for sem_post to disable signals around calls to > pthread functions. There are *no* async-signal safe pthread functions. No, the problem has already occurred when sem_post() is called. A signal occurs while blocked in pthread_cond_wait() but there is a race where the thread doesn't get removed from the CV queue then calls sem_post() which tries to requeue the thread on another synchronization queue. Normally when a signal interrupts a pthread_cond_wait(), the thread should get removed from the CV queue before calling the signal handler but this isn't happening. I am curious to see whether the fix I suggested solves the problem. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 15:55:07 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A3CE16A4CE; Wed, 3 Nov 2004 15:55:07 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8111143D2F; Wed, 3 Nov 2004 15:55:03 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.68.109] (HELO rogue.acs.lan) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP id 61946468; Wed, 03 Nov 2004 18:47:48 +0300 Received: by rogue.acs.lan (Postfix, from userid 1000) id 77E10B82F; Wed, 3 Nov 2004 18:54:42 +0300 (EAT) Date: Wed, 3 Nov 2004 18:54:42 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20041103155441.GA1601@rogue.acs.lan> References: <20041103141914.GA2095@rogue.acs.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/6.0-CURRENT (i386) cc: threads@freebsd.org cc: John Baldwin Subject: Re: More mono + libpthread breakage.. 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, 03 Nov 2004 15:55:07 -0000 On Wed, Nov 03, 2004 at 10:24:10AM -0500, Daniel Eischen wrote: > On Wed, 3 Nov 2004, Mike Makonnen wrote: > > No, the problem has already occurred when sem_post() is called. A signal > occurs while blocked in pthread_cond_wait() but there is a race where the > thread doesn't get removed from the CV queue then calls sem_post() which > tries to requeue the thread on another synchronization queue. Normally > when a signal interrupts a pthread_cond_wait(), the thread should get > removed from the CV queue before calling the signal handler but this > isn't happening. Ok, I misread the problem. However, even if my proposed solution doesn't help, the heart of the problem is that while sem_post is signal-safe, none of the pthreads API is safe. So you can call sem_post from within a signal handler, but sem_post cannot expect to safely call a pthreads function from within the signal handler; therefore, it has to find some other means of synchronization. While it is ok for a pthreads implementation to try to be more robust in these kinds of situations it certainly isn't required by the standard. So sem_post is relying on behaviour that is explicitly *not* guaranteed by POSIX (hence it is in-breach of its signal-safe status). I may be wrong, and welcome any corrections to my interpretation of the situation. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 16:11:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E10C416A4CE; Wed, 3 Nov 2004 16:11:21 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C95A43D62; Wed, 3 Nov 2004 16:11:21 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA3GBJkL012007; Wed, 3 Nov 2004 11:11:20 -0500 (EST) Date: Wed, 3 Nov 2004 11:11:19 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Mike Makonnen In-Reply-To: <20041103155441.GA1601@rogue.acs.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: John Baldwin Subject: Re: More mono + libpthread breakage.. 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, 03 Nov 2004 16:11:22 -0000 On Wed, 3 Nov 2004, Mike Makonnen wrote: > On Wed, Nov 03, 2004 at 10:24:10AM -0500, Daniel Eischen wrote: > > On Wed, 3 Nov 2004, Mike Makonnen wrote: > > > > No, the problem has already occurred when sem_post() is called. A signal > > occurs while blocked in pthread_cond_wait() but there is a race where the > > thread doesn't get removed from the CV queue then calls sem_post() which > > tries to requeue the thread on another synchronization queue. Normally > > when a signal interrupts a pthread_cond_wait(), the thread should get > > removed from the CV queue before calling the signal handler but this > > isn't happening. > > Ok, I misread the problem. However, even if my proposed solution doesn't help, > the heart of the problem is that while sem_post is signal-safe, none of the > pthreads API is safe. So you can call sem_post from within a signal handler, > but sem_post cannot expect to safely call a pthreads function from within > the signal handler; therefore, it has to find some other means of > synchronization. The sem_post implementation, like all libc locking should, uses _pthread_foo() (single underscore). Our thread library implementations are suppose to treat these specially when needed. The single underscore versions signify that they are being used for the implementation and should be treated as critical regions (disable or defer signals if necessary). > While it is ok for a pthreads implementation to try to be more robust in > these kinds of situations it certainly isn't required by the standard. So > sem_post is relying on behaviour that is explicitly *not* guaranteed by > POSIX (hence it is in-breach of its signal-safe status). > > I may be wrong, and welcome any corrections to my interpretation of > the situation. You're not wrong, it's just that our implementation should treat _pthread_foo() specially. We used the same pthread API because it is familiar, but it could just as well have been _libc_synch_obj_foo() or something. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 16:16:37 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 341C916A4CE; Wed, 3 Nov 2004 16:16:37 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 865DF43D2F; Wed, 3 Nov 2004 16:16:33 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.68.182] (HELO rogue.acs.lan) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP id 61947883; Wed, 03 Nov 2004 19:09:18 +0300 Received: by rogue.acs.lan (Postfix, from userid 1000) id A7BF0B82F; Wed, 3 Nov 2004 19:10:14 +0300 (EAT) Date: Wed, 3 Nov 2004 19:10:14 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20041103161014.GA54668@rogue.acs.lan> References: <20041103141914.GA2095@rogue.acs.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/6.0-CURRENT (i386) cc: threads@freebsd.org cc: John Baldwin Subject: Re: More mono + libpthread breakage.. 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, 03 Nov 2004 16:16:37 -0000 Ok, nevermind. I just took at it and sem_post is implemented in libpthread. So, whichever way you look at it the problem is with libpthread. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Thu Nov 4 01:33:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 076AD16A4CE; Thu, 4 Nov 2004 01:33:22 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D90AD43D2D; Thu, 4 Nov 2004 01:33:21 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) iA41XIHa085437; Thu, 4 Nov 2004 01:33:18 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41898827.6030005@freebsd.org> Date: Thu, 04 Nov 2004 09:38:47 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: More mono + libpthread breakage.. 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, 04 Nov 2004 01:33:22 -0000 Can you try signal fix for mono ? http://people.freebsd.org/~davidxu/kse/thr_sig.c.diff David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Nov 4 04:13:43 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E420416A4CE; Thu, 4 Nov 2004 04:13:43 +0000 (GMT) Received: from hellmouth3.gatech.edu (hellmouth3.gatech.edu [130.207.165.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35E5B43D2D; Thu, 4 Nov 2004 04:13:43 +0000 (GMT) (envelope-from gte990t@mail.gatech.edu) Received: from hellmouth3.gatech.edu (localhost [127.0.0.1]) by hellmouth3.gatech.edu (Postfix) with SMTP id CE5B6220EDB; Wed, 3 Nov 2004 23:13:42 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from mailprx3.gatech.edu (mailprx3.prism.gatech.edu [130.207.171.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (verified OK)) by hellmouth3.gatech.edu (Postfix) with ESMTP id 2B705220F05; Wed, 3 Nov 2004 23:13:37 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from [192.168.0.3] (r58h96.res.gatech.edu [128.61.58.96]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (sasl: method=PLAIN, username=gte990t, sender=n/a) by mailprx3.gatech.edu (Postfix) with ESMTP id C7E803A613; Wed, 3 Nov 2004 23:13:35 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) From: Jason Harmening Date: Wed, 3 Nov 2004 23:33:00 -0500 User-Agent: KMail/1.7 To: freebsd-current@freebsd.org, freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_8DbiB6Jw24SW9fy" Message-Id: <200411032333.00650.gte990t@mail.gatech.edu> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Fwd: Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state 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, 04 Nov 2004 04:13:44 -0000 --Boundary-00=_8DbiB6Jw24SW9fy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded Message ---------- Subject: Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state Date: Wednesday 03 November 2004 22:33 From: Jason Harmening To: Michael Nottebrock On Wednesday 03 November 2004 21:29, you wrote: > Could all people who are seeing this please post their kernel > configurations, sysctl.conf and perhaps some system details (platform, > UP/MP), too. > > Since I and nobody else of the KDE/FreeBSD people have yet seen this > problem and we're practically all running RELENG_5/RELENG_5_3 all the time, > I'm curious what might trigger this. uname -a: FreeBSD CORONA 5.3-RC2 FreeBSD 5.3-RC2 #0: Tue Nov 2 00:43:39 EST 2004 jason@CORONA:/usr/obj/usr/src/sys/CUSTOM i386 System: Athlon (classic) 800/Asus K7V/256MB, uniprocessor kldstat: Id Refs Address Size Name 1 1 0xc0400000 409d88 kernel pciconf -v -l: agp0@pci0:0:0: class=0x060000 card=0x80231043 chip=0x06911106 rev=0x02 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C691/693A/694X Apollo Pro/133/133A System Controller' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0x85981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'VT82C598MVP/694x Apollo MVP3/Pro133x PCI to AGP Bridge' class = bridge subclass = PCI-PCI isab0@pci0:4:0: class=0x060100 card=0x80231043 chip=0x06861106 rev=0x22 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686/A/B "Super South" PCI to ISA Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:4:1: class=0x01018a card=0x00000000 chip=0x05711106 rev=0x10hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxx EIDE Controller (All VIA Chipsets)' class = mass storage subclass = ATA uhci0@pci0:4:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB uhci1@pci0:4:3: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB hostb0@pci0:4:4: class=0x060000 card=0x00000000 chip=0x30571106 rev=0x30hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class = bridge subclass = HOST-PCI pcm0@pci0:10:0: class=0x040100 card=0x80271102 chip=0x00021102 rev=0x06 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10000 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL -CT4780' class = multimedia subclass = audio emujoy0@pci0:10:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x06hdr=0x00 vendor = 'Creative Labs' device = 'EMU10000 Game Port' class = input device atapci1@pci0:11:0: class=0x010400 card=0x4d39105a chip=0x4d30105a rev=0x02hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20267 FastTrack100 EIDE Controller' class = mass storage subclass = RAID sio4@pci0:12:0: class=0x070002 card=0x00d312b9 chip=0x100812b9 rev=0x01 hdr=0x00 vendor = '3COM Corp, Modem Division (Formerly US Robotics)' device = 'USR 56k Internal Modem' class = simple comms subclass = UART sis0@pci0:13:0: class=0x020000 card=0xf3111385 chip=0x0020100b rev=0x00 hdr=0x00 vendor = 'National Semiconductor' device = 'DP83815/16 Fast Ethernet Adapter (MacPhyter/MacPhyter-II)' class = network subclass = ethernet drm0@pci1:0:0: class=0x030000 card=0x00041002 chip=0x52461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc.' device = 'Rage 128 GL AGP 2x Rage Fury 16/32MB' class = display subclass = VGA dmesg Copyright (c) 1992-2004 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.3-RC2 #0: Tue Nov 2 00:43:39 EST 2004 jason@CORONA:/usr/obj/usr/src/sys/CUSTOM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (800.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ff AMD Features=0xc0400000 real memory = 268353536 (255 MB) avail memory = 252952576 (241 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0xe4000000-0xe7ffffff atdevice 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: port 0xd800-0xd8ff mem 0xdf000000-0xdf003fff,0xe0000000-0xe3ffffff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe4000000 64MB info: [drm] Initialized r128 2.5.0 20030725 on minor 0 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb400-0xb41f irq 9 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Brother HL-1850_1870N series, rev 1.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 3 uhub1: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 4, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: port 0xb000-0xb01f irq 9 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcm0: port 0x9400-0x941f irq 5 at device 10.0 on pci0 pcm0: atapci1: port 0x7400-0x743f,0x7800-0x7803,0x8000-0x8007,0x8400-0x8403,0x8800-0x8807 mem 0xde800000-0xde81ffff irq 10 at device 11.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 sio0: <3COM PCI FaxModem> port 0x7000-0x7007 irq 11 at device 12.0 on pci0 sio0: moving to sio4 sio4: type 16550A sis0: port 0x6800-0x68ff mem 0xde000000-0xde000fff irq 9 at device 13.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:09:5b:1f:0c:d6 cpu0 on motherboard orm0: at iomem 0xd0000-0xd7fff,0xcc000-0xcffff,0xc0000-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> can't re-use a leaf (%desc)! can't re-use a leaf (%driver)! can't re-use a leaf (%location)! can't re-use a leaf (%pnpinfo)! can't re-use a leaf (%parent)! sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) Timecounter "TSC" frequency 800034660 Hz quality 800 Timecounters tick every 10.000 msec ata0-slave: FAILURE - ATAPI_IDENTIFY status=1 error=4 LBA=0 ata0-slave: FAILURE - ATAPI_IDENTIFY status=1 error=4 LBA=0 acd0: CDRW at ata1-master UDMA33 ad4: 19623MB [39870/16/63] at ata2-master UDMA100 ad6: 19623MB [39870/16/63] at ata3-master UDMA100 ar0: 39246MB [5003/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ata0 bus 0 target 0 lun 0 da0: Removable Optical SCSI-4 device da0: 33.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:ata0:0:0:0): CAM Status: SCSI Status Error (da0:ata0:0:0:0): SCSI Status: Check Condition (da0:ata0:0:0:0): NOT READY asc:3a,0 (da0:ata0:0:0:0): Medium not present (da0:ata0:0:0:0): Unretryable error Opened disk da0 -> 6 (da0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:ata0:0:0:0): CAM Status: SCSI Status Error (da0:ata0:0:0:0): SCSI Status: Check Condition (da0:ata0:0:0:0): NOT READY asc:3a,0 (da0:ata0:0:0:0): Medium not present (da0:ata0:0:0:0): Unretryable error Opened disk da0 -> 6 (da0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:ata0:0:0:0): CAM Status: SCSI Status Error (da0:ata0:0:0:0): SCSI Status: Check Condition (da0:ata0:0:0:0): NOT READY asc:3a,0 (da0:ata0:0:0:0): Medium not present (da0:ata0:0:0:0): Unretryable error Opened disk da0 -> 6 Mounting root from ufs:/dev/ar0s1a The problem occurs primarily when loading OpenOffice under a relatively heavy load (almost always with KDE and Netbeans IDE also running, both of which are memory hogs.) The system has a 1GB swap partition, and this load never created any problems for 5.2.1. Also, my laptop, which has 512 megs of RAM and runs fluxbox instead of KDE, has not yet encountered this problem under similar loads. I've recompiled parts of KDE and also the JDK (native 1.4.2), with no effect. I also have libc_r libmapped to libpthread. Currently, OpenOffice will not compile on my system, which leads me to the next question: Is it possible that OpenOffice, which was originally compiled under 5.2.1, has the old libc_r (or at least part of it) statically compiled in, so that it is somehow interfering with the new threading model? Let me know if I can be of any help... Thanks, Jason Harmening - ------------------------------------------------------- --Boundary-00=_8DbiB6Jw24SW9fy Content-Type: text/plain; charset="iso-8859-1"; name="sysctl.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl.conf" # $FreeBSD: src/etc/sysctl.conf,v 1.8 2003/03/13 18:43:50 mux Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet6.ip6.v6only=0 --Boundary-00=_8DbiB6Jw24SW9fy Content-Type: text/plain; charset="iso-8859-1"; name="loader.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loader.conf" hw.ata.atapi_dma="1" --Boundary-00=_8DbiB6Jw24SW9fy Content-Type: text/plain; charset="iso-8859-1"; name="CUSTOM" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="CUSTOM" # # 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 ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.48 2002/08/31 20:28:26 obrien Exp $ machine i386 cpu I686_CPU ident CUSTOM #makeoptions DEBUG=-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_LINUX options LINPROCFS options GEOM_GPT options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000 #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 options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT device apic device isa device eisa device pci device agp # Minimum required SCSI devices device scbus # SCSI bus (required) device da # Direct Access (disks) device cd #SCSI CD-ROMs device pass #CAM passthrough driver # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapicam # emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) options ATA_STATIC_ID #Static device numbering # 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 device splash # Splash screen and screen saver support device "r128drm" # 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 # Floating point support - do not disable. device npx #device puc # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs. device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 # Pseudo devices - the number indicates how many units to allocate. device mem device io 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' pseudo-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 usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ulpt # Printer device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uscanner # Scanners device sound device "snd_emu10k1" --Boundary-00=_8DbiB6Jw24SW9fy Content-Type: text/plain; charset="iso-8859-1"; name="rc.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.conf" # -- sysinstall generated deltas -- # Sat Mar 15 23:57:05 2003 # Created: Sat Mar 15 23:57:05 2003 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="CORONA" ifconfig_sis0="DHCP" kern_securelevel_enable="NO" linux_enable="YES" sendmail_enable="YES" sshd_enable="YES" usbd_enable="YES" network_interfaces="lo0 sis0" # This file now contains just the overrides from /etc/defaults/rc.conf. # Please make all changes to this file, not to /etc/defaults/rc.conf. # Enable network daemons for user convenience. # Created: Wed Jun 16 00:29:02 2004 --Boundary-00=_8DbiB6Jw24SW9fy-- From owner-freebsd-threads@FreeBSD.ORG Thu Nov 4 12:00:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E920116A4E2; Thu, 4 Nov 2004 12:00:59 +0000 (GMT) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028D243D2D; Thu, 4 Nov 2004 12:00:59 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.1/8.13.1) with ESMTP id iA4C0pUN098159; Thu, 4 Nov 2004 13:00:51 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <418A19F3.6040403@fer.hr> Date: Thu, 04 Nov 2004 13:00:51 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.8 (X11/20041021) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <41898827.6030005@freebsd.org> In-Reply-To: <41898827.6030005@freebsd.org> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: More mono + libpthread breakage.. 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, 04 Nov 2004 12:01:00 -0000 David Xu wrote: > Can you try signal fix for mono ? > > http://people.freebsd.org/~davidxu/kse/thr_sig.c.diff Is this about the threads/72353 PR? I tried it and I still get the same assertion failure in libpthread. From owner-freebsd-threads@FreeBSD.ORG Thu Nov 4 22:25:14 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ABDC16A4ED for ; Thu, 4 Nov 2004 22:25:14 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAA5343D45 for ; Thu, 4 Nov 2004 22:25:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12271 invoked from network); 4 Nov 2004 22:25:13 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 22:25:12 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4MP5wL089030; Thu, 4 Nov 2004 17:25:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: David Xu Date: Thu, 4 Nov 2004 16:03:50 -0500 User-Agent: KMail/1.6.2 References: <41898827.6030005@freebsd.org> In-Reply-To: <41898827.6030005@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041603.50926.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: threads@FreeBSD.org Subject: Re: More mono + libpthread breakage.. 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, 04 Nov 2004 22:25:14 -0000 On Wednesday 03 November 2004 08:38 pm, David Xu wrote: > Can you try signal fix for mono ? > > http://people.freebsd.org/~davidxu/kse/thr_sig.c.diff Didn't seem to make a change. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Fri Nov 5 16:40:29 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB7ED16A4D1; Fri, 5 Nov 2004 16:40:29 +0000 (GMT) Received: from hellmouth7.gatech.edu (hellmouth7.gatech.edu [130.207.165.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B1C643D2D; Fri, 5 Nov 2004 16:40:18 +0000 (GMT) (envelope-from gte990t@mail.gatech.edu) Received: from hellmouth7.gatech.edu (localhost [127.0.0.1]) by hellmouth7.gatech.edu (Postfix) with SMTP id A4C50226F; Fri, 5 Nov 2004 11:40:17 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from mailprx2.gatech.edu (mailprx2.prism.gatech.edu [130.207.171.21]) by hellmouth7.gatech.edu (Postfix) with ESMTP id 8EDD02123; Fri, 5 Nov 2004 11:40:17 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) Received: from [192.168.0.3] (r58h96.res.gatech.edu [128.61.58.96]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (sasl: method=PLAIN, username=gte990t, sender=n/a) by mailprx2.gatech.edu (Postfix) with ESMTP id 448B23A612; Fri, 5 Nov 2004 11:40:15 -0500 (EST) (envelope-from gte990t@mail.gatech.edu) From: Jason Harmening To: Alex Dupre , Boris Kovalenko , Michael Nottebrock Date: Fri, 5 Nov 2004 11:59:31 -0500 User-Agent: KMail/1.7 References: <200411020143.34251.gte990t@mail.gatech.edu> <418792ED.8010700@alexdupre.com> In-Reply-To: <418792ED.8010700@alexdupre.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411051159.32077.gte990t@mail.gatech.edu> cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 16:40:30 -0000 The following patch, sent to me from David Xu by way of Marc Ramirez, seems to fix the "unkillable process" problem: Index: kern_thread.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v retrieving revision 1.205 diff -u -r1.205 kern_thread.c --- kern_thread.c 4 Nov 2004 22:13:16 -0000 1.205 +++ kern_thread.c 5 Nov 2004 04:23:24 -0000 @@ -832,11 +832,10 @@ continue; /* * maybe other inhibitted states too? - * XXXKSE Is it totally safe to - * suspend a non-interruptable thread? */ - if (td2->td_inhibitors & - (TDI_SLEEPING | TDI_SWAPPED)) + if ((td2->td_flags & TDF_SINTR) && + (td2->td_inhibitors & + (TDI_SLEEPING | TDI_SWAPPED))) thread_suspend_one(td2); break; } On Tuesday 02 November 2004 09:00, you wrote: > Jason Harmening wrote: > > I just upgraded to 5.3-RC2, and I'm still running into the problem where > > processes will hang in an unkillable state. In particular, this happens > > for me with OpenOffice under a heavy load. 'ps' reports the state as > > 'TL' and 'top' reports the state as STOP. Neither kill -CONT nor kill > > -KILL will work. > > Same here. With OpenOffice and Java under high load. From owner-freebsd-threads@FreeBSD.ORG Fri Nov 5 18:38:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B797B16A523 for ; Fri, 5 Nov 2004 18:38:42 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDAA943D1F for ; Fri, 5 Nov 2004 18:38:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id A1ADF7A424 for ; Fri, 5 Nov 2004 10:38:37 -0800 (PST) Message-ID: <418BC8AD.8030207@elischer.org> Date: Fri, 05 Nov 2004 10:38:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: threads@freebsd.org Content-Type: multipart/mixed; boundary="------------030803020700050405040308" Subject: [Fwd: Re: 5.3-RC2: kqueue descriptor leak in resolver functions?] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 18:38:46 -0000 This is a multi-part message in MIME format. --------------030803020700050405040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------030803020700050405040308 Content-Type: message/rfc822; name="Re: 5.3-RC2: kqueue descriptor leak in resolver functions?" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: 5.3-RC2: kqueue descriptor leak in resolver functions?" Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by idiom.com (8.12.11/8.12.11) with ESMTP id iA5DR0eM076633 for ; Fri, 5 Nov 2004 05:27:00 -0800 (PST) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5F5DF56436 for ; Fri, 5 Nov 2004 13:26:59 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: by hub.freebsd.org (Postfix) id C2BE616A50E; Fri, 5 Nov 2004 13:26:53 +0000 (GMT) Delivered-To: julian@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B10FF16A50B; Fri, 5 Nov 2004 13:26:53 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E30EF16A4CE; Thu, 4 Nov 2004 22:24:21 +0000 (GMT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4EF43D46; Thu, 4 Nov 2004 22:24:21 +0000 (GMT) (envelope-from lennox@cs.columbia.edu) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA4MNTRX027889; Thu, 4 Nov 2004 17:23:30 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA4MNTi7058350; Thu, 4 Nov 2004 17:23:29 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id iA4MNT7g058344; Thu, 4 Nov 2004 17:23:29 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16778.44000.981070.769175@cnr.cs.columbia.edu> Date: Thu, 4 Nov 2004 17:23:28 -0500 To: Arjan de Vet In-Reply-To: <20041102094145.GA4698@adv.devet.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.11.4.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Mailman-Approved-At: Fri, 05 Nov 2004 13:26:50 +0000 Cc: re@freebsd.org Cc: current@freebsd.org Subject: Re: 5.3-RC2: kqueue descriptor leak in resolver functions? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Accessio-Status: NO, score=0.00,none version=6.0 count=0 X-Accessio-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on mx.idiom.com X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=failed version=3.0.0 X-Idiom-Reporting: If this was spam, please report it to spamcop.net Arjan de Vet writes: > A ktrace of the mozilla process seems to point to the DNS resolver code > leaking kqueue descriptors (I could not find any kqueue() calls in the > mozilla code itself). I've noticed (and reported) this with 5.2.1, in the specific case when you're using libc_r and linking statically. I never heard anything back, though. The problem is that 'kqueue' isn't namespace'd (#defined as _kqueue) in lib/libc/include/[un]namespace.h, and the thread libraries don't draw in _kqueue in their 'references' array. Attached below is a patch against 5.2.1. It should apply to 5.3-RC2 as well. The patch for lib/libc_r/uthread/uthread_init.c may also need to be applied to lib/libpthread/thread/thr_init.c and lib/libthr/thread/thr_init.c. See PR bin/58687. --- lib/libc_r/uthread/uthread_init.c.orig Wed Oct 29 11:00:53 2003 +++ lib/libc_r/uthread/uthread_init.c Wed Oct 29 11:01:21 2003 @@ -99,6 +99,7 @@ &_getsockopt, &_ioctl, &_kevent, + &_kqueue, &_listen, &_nanosleep, &_open, --- lib/libc/include/namespace.h.orig Wed Oct 29 14:13:09 2003 +++ lib/libc/include/namespace.h Wed Oct 29 14:13:31 2003 @@ -77,6 +77,7 @@ #define getsockopt _getsockopt #define ioctl _ioctl /* #define kevent _kevent */ +#define kqueue _kqueue #define listen _listen #define nanosleep _nanosleep #define open _open --- lib/libc/include/un-namespace.h.orig Wed Oct 29 14:13:13 2003 +++ lib/libc/include/un-namespace.h Wed Oct 29 14:13:55 2003 @@ -58,6 +58,7 @@ #undef getsockopt #undef ioctl #undef kevent +#undef kqueue #undef listen #undef nanosleep #undef open -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ 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" --------------030803020700050405040308-- From owner-freebsd-threads@FreeBSD.ORG Fri Nov 5 20:46:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE17D16A4CE for ; Fri, 5 Nov 2004 20:46:30 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 707BA43D41 for ; Fri, 5 Nov 2004 20:46:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA5KkRRD011102; Fri, 5 Nov 2004 15:46:27 -0500 (EST) Date: Fri, 5 Nov 2004 15:46:27 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <418BC8AD.8030207@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=------------030803020700050405040308 Content-ID: X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: [Fwd: Re: 5.3-RC2: kqueue descriptor leak in resolver functions?] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 20:46:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------030803020700050405040308 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: On Fri, 5 Nov 2004, Julian Elischer wrote: > > The namespace changes are not necessary unless the libc code that uses kqueue() is changed to use _kqueue() (in libc/net/ and libc/rpc/). -- Dan Eischen --------------030803020700050405040308 Content-Type: MESSAGE/RFC822; NAME="Re: 5.3-RC2: kqueue descriptor leak in resolver functions?" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="Re: 5.3-RC2: kqueue descriptor leak in resolver functions?" Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by idiom.com (8.12.11/8.12.11) with ESMTP id iA5DR0eM076633 for ; Fri, 5 Nov 2004 05:27:00 -0800 (PST) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 5F5DF56436 for ; Fri, 5 Nov 2004 13:26:59 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: by hub.freebsd.org (Postfix) id C2BE616A50E; Fri, 5 Nov 2004 13:26:53 +0000 (GMT) Delivered-To: julian@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B10FF16A50B; Fri, 5 Nov 2004 13:26:53 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E30EF16A4CE; Thu, 4 Nov 2004 22:24:21 +0000 (GMT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4EF43D46; Thu, 4 Nov 2004 22:24:21 +0000 (GMT) (envelope-from lennox@cs.columbia.edu) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA4MNTRX027889; Thu, 4 Nov 2004 17:23:30 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iA4MNTi7058350; Thu, 4 Nov 2004 17:23:29 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id iA4MNT7g058344; Thu, 4 Nov 2004 17:23:29 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16778.44000.981070.769175@cnr.cs.columbia.edu> Date: Thu, 4 Nov 2004 17:23:28 -0500 To: Arjan de Vet In-Reply-To: <20041102094145.GA4698@adv.devet.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.11.4.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Mailman-Approved-At: Fri, 05 Nov 2004 13:26:50 +0000 Cc: re@freebsd.org Cc: current@freebsd.org Subject: Re: 5.3-RC2: kqueue descriptor leak in resolver functions? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Accessio-Status: NO, score=0.00,none version=6.0 count=0 X-Accessio-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on mx.idiom.com X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=failed version=3.0.0 X-Idiom-Reporting: If this was spam, please report it to spamcop.net Arjan de Vet writes: > A ktrace of the mozilla process seems to point to the DNS resolver code > leaking kqueue descriptors (I could not find any kqueue() calls in the > mozilla code itself). I've noticed (and reported) this with 5.2.1, in the specific case when you're using libc_r and linking statically. I never heard anything back, though. The problem is that 'kqueue' isn't namespace'd (#defined as _kqueue) in lib/libc/include/[un]namespace.h, and the thread libraries don't draw in _kqueue in their 'references' array. Attached below is a patch against 5.2.1. It should apply to 5.3-RC2 as well. The patch for lib/libc_r/uthread/uthread_init.c may also need to be applied to lib/libpthread/thread/thr_init.c and lib/libthr/thread/thr_init.c. See PR bin/58687. --- lib/libc_r/uthread/uthread_init.c.orig Wed Oct 29 11:00:53 2003 +++ lib/libc_r/uthread/uthread_init.c Wed Oct 29 11:01:21 2003 @@ -99,6 +99,7 @@ &_getsockopt, &_ioctl, &_kevent, + &_kqueue, &_listen, &_nanosleep, &_open, --- lib/libc/include/namespace.h.orig Wed Oct 29 14:13:09 2003 +++ lib/libc/include/namespace.h Wed Oct 29 14:13:31 2003 @@ -77,6 +77,7 @@ #define getsockopt _getsockopt #define ioctl _ioctl /* #define kevent _kevent */ +#define kqueue _kqueue #define listen _listen #define nanosleep _nanosleep #define open _open --- lib/libc/include/un-namespace.h.orig Wed Oct 29 14:13:13 2003 +++ lib/libc/include/un-namespace.h Wed Oct 29 14:13:55 2003 @@ -58,6 +58,7 @@ #undef getsockopt #undef ioctl #undef kevent +#undef kqueue #undef listen #undef nanosleep #undef open -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ 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" --------------030803020700050405040308 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ 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" --------------030803020700050405040308--