From owner-freebsd-threads@FreeBSD.ORG Thu May 1 13:21:05 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 B765A37B401; Thu, 1 May 2003 13:21:05 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836FB43FAF; Thu, 1 May 2003 13:21:04 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41KKuBg029130; Thu, 1 May 2003 16:20:56 -0400 (EDT) Received: from localhost (eischen@localhost)h41KKuUn029126; Thu, 1 May 2003 16:20:56 -0400 (EDT) Date: Thu, 1 May 2003 16:20:56 -0400 (EDT) From: Daniel Eischen To: Vallo Kallaste In-Reply-To: <20030501200911.GA721@kevad.internal> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: threads@freebsd.org cc: Julian Elischer Subject: Re: libkse observations [Was: Re: libthr broken] 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, 01 May 2003 20:21:06 -0000 On Thu, 1 May 2003, Vallo Kallaste wrote: > On Wed, Apr 30, 2003 at 11:25:04AM -0400, Daniel Eischen > wrote: > > > I just committed a fix for this. I can now run knode, although I > > get: > > > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > > > I am running kde3.1 but built with X 4.2.99 from the XFree86 CVS tree (not > > via the port), so that may have something to do with it. > > The kdecore messages are harmless and present even with libc_r. > Now KNode starts up and is useable as before and the same bugs as > before remain. I have configured KNode to start up external editor > (gvim), which it does. After editing and :wq KNode still thinks that > external editor is running while it's long gone. The text from the > temporary file (/tmp/kde-vallo/knode?????) will not be transferred > to KNode's native text editor window. Closing KNode gets rid of the > KNode UI, but it remains running accordingly to ps and top. It has > no state per top and is killable via TERM. I think there is something wrong with SIGCHLD not getting properly sent/received to libkse processes, or perhaps libkse just doesn't dispatch the signal correctly. > Mozilla still will not start up. It's present in the process table > but no UI will show up. Top will show mozilla process steadily in > the RUN state, using zero CPU and it's not killable via TERM. This is a bug in rtld-elf as discussed earlier on this list (threads@). It isn't thread-safe and the tricks it uses to prevent thread swap-out work for libc_r, but not for libkse. This problem was just added to the TODO list for 5.1-release. Here's a hack to libpthread to temporarily get around this problem, though it might cause other problems (allowing CPU hungry threads to starve other threads). -- Dan Eischen Index: thread/thr_kern.c =================================================================== RCS file: /home/ncvs/src/lib/libpthread/thread/thr_kern.c,v retrieving revision 1.62 diff -u -r1.62 thr_kern.c --- thread/thr_kern.c 30 Apr 2003 15:05:17 -0000 1.62 +++ thread/thr_kern.c 1 May 2003 20:19:02 -0000 @@ -784,7 +784,8 @@ if (curthread == NULL) ; /* Nothing to do here. */ else if ((curthread->need_switchout == 0) && - (curthread->blocked == 0) && (THR_IN_CRITICAL(curthread))) { + (curthread->blocked == 0) && + ((THR_IN_CRITICAL(curthread)) || (curthread->state == PS_RUNNING))) { /* * Resume the thread and tell it to yield when * it leaves the critical region.