Date: Thu, 30 Aug 2001 05:14:47 +0900 From: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> To: Daniel Eischen <eischen@vigrid.com> Cc: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp>, hackers@FreeBSD.ORG Subject: Re: libc_r, signals and modifying sigcontext Message-ID: <55heuqipxk.wl@tripper.private> In-Reply-To: <Pine.SUN.3.91.1010829141318.10649A-100000@pcnet1.pcnet.com> References: <55k7zmiwop.wl@tripper.private> <Pine.SUN.3.91.1010829141318.10649A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At Wed, 29 Aug 2001 14:31:25 -0400 (EDT),
Daniel Eischen wrote:
>
> On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> > Hi all,
> >
> > I'm also wondering how to use signals to handle runtime exceptions
> > such as SIGFPE and SIGSEGV in pthread application. These signals are
> > often used by implementation of Java VM to handle Java's runtime
> > exceptions. Almost same scheme works fine in non-pthread application
> > but it doesn't in pthread application.
> >
> > `test.c' gives the simplified version of this problem (the program
> > assumes x86). When I use _thread_sys_sigreturn someone suggests, the
> > first signal is caught by signal handler on the current thread that
> > cause the exception but signals after second attempts are never caught
> > on the current thread. This is because the sigmask for signal handler
> > thread, the current thread at first signal, is masked at
> > uthread_sig.c(line 1070) and it isn't recovered when
> > _thread_sys_sigreturn is called.
> >
> > So we need `sigreturn' function for libc_r instead of using
> > _thread_sys_sigreturn. `uthread_sigreturn.c` gives a simple
> > implementation of sigreturn for 4.3-STABLE(4.4-RC). When I use
> > sigreturn (implemented at `uthread_sigreturn.c') instead
> > of_thread_sys_sigreturn in `test.c', the program works as I expected.
> >
> >
> > How do you think to add sigreturn function into libc_r?
>
> Your implementation of sigreturn is not correct for our threads
> library. You don't need the strong reference in -current.
Does it need in -stable?
> The signal mask in the ucontext_t is the _process_ signal
> mask. This is not the threads signal mask which can be
> different. It may work in your case because your threads
> don't change their signal mask, so it may be the same as
> the process signal mask.
Right, I made mistakes, my sample is too simplified. Now I understand
it, thanks.
> I'm not sure what sigreturn should do in a threaded environment,
> particularly if it should restore the threads signal mask or
> not.
At least on Solaris, we can restore sigmask for thread at signal
handler using setcontext(uc) to return from signal handler, but I'm
not sure ucontext in Solaris is whether per thread object or per
process object. On the other hand, we cannot restore the sigmask for
thread when we return from signal handler with libc_r. So we need
similar function as Solaris's setcontext, of course setcontext may do
more than sigreturn do. And the most important fact is we cannot
implement sigreturn in user programs because it need to know the
actual implementation of thread library.
Java VM needs this function. My previous example explains how JIT
compiled codes in Java VM works. Actual codes which may cause SIGSEGV
or SIGFPE does not always raise signals.
> In order to make it work the you want it to, and I'm
> not sure that is the correct thing yet, you need to change
> the signal mask in the ucontext before the signal handler
> is invoked. This would be done somewhere in uthread_sig.c.
> You would put the threads signal mask (before OR'ing in
> the sa_mask from the installed handler) into the ucontext.
> This would make the ucontext passed to a signal handler
> contain that threads signal mask, not the process signal
> mask. Then when implementing sigreturn, you restore the
> threads signal mask from the ucontext, place the process
> signal mask in the ucontext, and _thread_sys_sigreturn().
>
> Here's a quick (uncompiled, untested) attempt at a fix.
>
> Index: uthread/uthread_sig.c
> ===================================================================
> RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_sig.c,v
> retrieving revision 1.25.2.8
> diff -u -r1.25.2.8 uthread_sig.c
> --- uthread/uthread_sig.c 2001/07/06 12:31:25 1.25.2.8
> +++ uthread/uthread_sig.c 2001/08/29 18:29:39
> @@ -1063,6 +1063,7 @@
> sizeof(psf->uc));
> memcpy(&psf->siginfo, &_thread_sigq[psf->signo - 1].siginfo,
> sizeof(psf->siginfo));
> + psf->uc.uc_sigmask = thread->sigmask;
> }
>
> /* Setup the signal mask: */
>
>
>
> #include <sys/param.h>
> #include <sys/types.h>
> #include <sys/signalvar.h>
> #include <signal.h>
>
> #ifdef _THREAD_SAFE
> #include <pthread.h>
> #include "pthread_private.h"
>
> int
> _sigreturn(ucontext_t *ucp)
> {
> _thread_run->sigmask = ucp->uc_sigmask;
> ucp->uc_sigmask = _process_sigmask;
> return (_thread_sys_sigreturn(ucp));
> }
>
> __strong_reference(_sigreturn, sigreturn);
> #endif
Your patch seems to work, yes I tried with test.c modified to specify
per thread sigmask. But now I have worry about when there are another
signals pended. The actual work needed for sigreturn is restore the
sigmask to unblock the very signal masked at uthread_sig.c(line 1070)
temporarily. Using thread->sigmask for sigreturn may do overwork.
How do you think about this?
--
Fuyuhiko MARUYAMA <fuyuhik8@is.titech.ac.jp>
Matsuoka laboratory,
Department of Mathematical and Computing Sciences,
Graduate School of Information Science and Engineering,
Tokyo Institute of Technology.
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?55heuqipxk.wl>