From owner-freebsd-hackers Tue Dec 4 10: 0:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id F2D0037B41E; Tue, 4 Dec 2001 10:00:03 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 44B1081D01; Tue, 4 Dec 2001 11:59:59 -0600 (CST) Date: Tue, 4 Dec 2001 11:59:59 -0600 From: Alfred Perlstein To: Dan Eischen Cc: Louis-Philippe Gagnon , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc_r pthread bug Message-ID: <20011204115959.J92148@elvis.mu.org> References: <094601c179ea$7cca85c0$2964a8c0@MACADAMIAN.com> <20011204021815.E92148@elvis.mu.org> <3C0CC2FE.275F4C68@vigrid.com> <20011204114236.H92148@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011204114236.H92148@elvis.mu.org>; from bright@mu.org on Tue, Dec 04, 2001 at 11:42:36AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Alfred Perlstein [011204 11:45] wrote: > * Dan Eischen [011204 06:26] wrote: > > > > There are already cancellation tests when resuming threads > > whose contexts are not saved as a result of a signal interrupt > > (ctxtype != CTX_UC). You shouldn't test for cancellation when > > ctxtype == CTX_UC because you are running on the scheduler > > stack, not the threads stack. > > That makes sense, but why? > > > You also have a bug in the > > way you changed the check for cancellation flags. > > What? > > > There only clean way to fix this is to add a return frame > > to the interrupted context so that it can check for cancellation > > (and other things) before returning to the threads interrupted > > context. > > No way to work around this? Shouldn't the thread exit library > know which stack exactly to clean up even in the context of a > signal handler? Are you sure this is 100% needed? Here's a recap of that patch, are you saying that the problem is that the thread will use the current sp if it exits rather than some value stashed away in the private pthread struct? Also, I think my tests for cancellation are correct. Although I sort of think the PTHREAD_AT_CANCEL_POINT test should be removed because the code will catch this when it leaves the cancellation point. Index: uthread_kern.c =================================================================== RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v retrieving revision 1.39 diff -u -r1.39 uthread_kern.c --- uthread_kern.c 7 Oct 2001 02:34:43 -0000 1.39 +++ uthread_kern.c 4 Dec 2001 17:58:31 -0000 @@ -180,7 +180,7 @@ struct pthread *curthread = _get_curthread(); pthread_t pthread, pthread_h; unsigned int current_tick; - int add_to_prioq; + int add_to_prioq, cfl; /* If the currently running thread is a user thread, save it: */ if ((curthread->flags & PTHREAD_FLAGS_PRIVATE) == 0) @@ -604,6 +604,15 @@ */ _thread_kern_in_sched = 0; + /* + * test for async cancel: + */ + cfl = curthread->cancelflags; + + cfl &= (PTHREAD_CANCEL_ASYNCHRONOUS| + PTHREAD_AT_CANCEL_POINT); + if (cfl != 0) + pthread_testcancel(); #if NOT_YET _setcontext(&curthread->ctx.uc); #else @@ -1078,6 +1087,8 @@ curthread->sig_defer_count--; } else if (curthread->sig_defer_count == 1) { + int cfl; + /* Reenable signals: */ curthread->sig_defer_count = 0; @@ -1091,8 +1102,9 @@ * Check for asynchronous cancellation before delivering any * pending signals: */ - if (((curthread->cancelflags & PTHREAD_AT_CANCEL_POINT) == 0) && - ((curthread->cancelflags & PTHREAD_CANCEL_ASYNCHRONOUS) != 0)) + cfl = curthread->cancelflags; + cfl &= (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT); + if (cfl != 0) pthread_testcancel(); /* -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message