From owner-freebsd-current Tue Jul 2 14: 6:50 2002 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 39FDC37B6BB for ; Tue, 2 Jul 2002 14:05:54 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90D5F4416E for ; Tue, 2 Jul 2002 10:00:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020702170019.IVHS8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 2 Jul 2002 17:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA97396; Tue, 2 Jul 2002 09:51:43 -0700 (PDT) Date: Tue, 2 Jul 2002 09:51:41 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: Jonathan Lemon , iedowse@maths.tcd.ie, current@FreeBSD.ORG Subject: Re: KSE status report In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just removed the extra debug line in queue.h that set the "next" pointer to -1 then the element was removed. Since I was told that the problem still occurs with an old queue.h I don;t think that that will fix it but we might as well try it again with this change. On Tue, 2 Jul 2002, Daniel Eischen wrote: > On Tue, 2 Jul 2002, Jonathan Lemon wrote: > > In article you write: > > >In message , Ju > > >lian Elischer writes: > > >>The big problem at the moment is that something in the > > >>source tree as a whole, and probably something that came in with KSE > > >>is stopping us from successfully compiling a working libc_r. > > >>(a bit ironic really). > > > > > >Is the new > > > > > > (elm)->field.tqe_next = (void *)-1; > > > > > >in TAILQ_REMOVE a likely candidate? That could easily tickle old > > >bugs in other code. The libc_r code does use a lot of TAILQ macros. > > > > >From casual inspection of the sources, it appears this may be the case: > > > > uthread/pthread_private.h: > > #define PTHREAD_WORKQ_REMOVE(thrd) do { \ > > TAILQ_REMOVE(&_workq,thrd,qe); \ > > (thrd)->flags &= ~PTHREAD_FLAGS_IN_WORKQ; \ > > } while (0) > > > > uthread/uthread_kern.c (in multiple locations): > > TAILQ_FOREACH(pthread, &_workq, qe) { > > .... > > PTHREAD_WORKQ_REMOVE(pthread); > > } > > This used to be safe as long as the element removed wasn't re-added to > another queue using the same link. There are other places in libc_r > where we do re-use the same link (remove from one list and add to > another), but roll our own loop in that case: > > for (p = TAILQ_FIRST(&q); p != NULL; p = p_next) { > p_next = TAILQ_NEXT(p, p_qe); > ... > TAILQ_REMOVE(&q, pthread, p_qe); > ... > } > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message