Date: Tue, 4 Dec 2001 11:59:59 -0600 From: Alfred Perlstein <bright@mu.org> To: Dan Eischen <eischen@vigrid.com> Cc: Louis-Philippe Gagnon <louisphilippe@macadamian.com>, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc_r pthread bug Message-ID: <20011204115959.J92148@elvis.mu.org> In-Reply-To: <20011204114236.H92148@elvis.mu.org>; from bright@mu.org on Tue, Dec 04, 2001 at 11:42:36AM -0600 References: <094601c179ea$7cca85c0$2964a8c0@MACADAMIAN.com> <Pine.SUN.3.91.1011130170847.14642A-100000@pcnet1.pcnet.com> <20011204021815.E92148@elvis.mu.org> <3C0CC2FE.275F4C68@vigrid.com> <20011204114236.H92148@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Alfred Perlstein <bright@mu.org> [011204 11:45] wrote:
> * Dan Eischen <eischen@vigrid.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011204115959.J92148>