Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2001 12:07:50 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Stefan Hoffmeister <freebsd-ml@econos.de>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: libc_r, signal handler ucontext modification
Message-ID:  <Pine.SUN.3.91.1010607115002.18858A-100000@pcnet1.pcnet.com>
In-Reply-To: <if4vht0v8dlrc51kuokta0cs0r5p7flef9@4ax.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Jun 2001, Stefan Hoffmeister wrote:
> : On Thu, 07 Jun 2001 15:21:31 +0200, Stefan Hoffmeister wrote:
> 
> >I admit that all this is somewhat anecdotal, but I haven't looked in
> >detail yet at what happens after the signal handler has returned to
> >
> >  uthread/uthread_sig.c -> _thread_sig_wrapper
> 
> Looking at code in question, I wonder whether in uthread_sig.c this code:
> 
> *********************************
> static void
> thread_sigframe_add(pthread_t thread, int sig, int has_args)
> {
> 
> ...
> 
> 	if (has_args) {
> 		/* Copy the signal handler arguments to the signal frame: */
> 		memcpy(&psf->uc, &_thread_sigq[psf->signo - 1].uc,
> 		    sizeof(psf->uc));
> 		memcpy(&psf->siginfo, &_thread_sigq[psf->signo - 1].siginfo,
> 		    sizeof(psf->siginfo));
> 	}
> ...
> *********************************
> 
> should get matching code
> 
> *********************************
> 
> void
> _thread_sigframe_restore(pthread_t thread, struct pthread_signal_frame
> *psf)
> {
> 	thread->ctxtype = psf->ctxtype;
> -	memcpy(&thread->ctx.uc, &psf->ctx.uc, sizeof(thread->ctx.uc));
> +	if (psf->sig_has_args)
> +		memcpy(&thread->ctx.uc, &psf->uc, sizeof(thread->ctx.uc));
> +	else
> +		memcpy(&thread->ctx.uc, &psf->ctx.uc, sizeof(thread->ctx.uc));
> 
> *********************************

You can't do that.  There is no requirement that the interrupted thread
is the one that handles the signal.  If you copy the context back to
the current threads context storage, then you'll possibly end up with
2 threads running (or trying to run) on the same stack!

The only way to make that work is to suspend the thread that got 
interrupted until the signal handler finished.  And we can never know
when the signal handler finishes because the handler is allowed to
longjmp out [of the handler].

You could potentially copy the context back if and only if the thread
that was interrupted is the same as the thread that is handling the
signal.  You could also easily modify the context and do a
sigreturn(ucp) on it to achieve the same effect (being careful to make 
sure you're not trying to jump to another threads context).

-- 
Dan Eischen

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?Pine.SUN.3.91.1010607115002.18858A-100000>