From owner-freebsd-hackers Wed Aug 29 13:12:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from matsulab.is.titech.ac.jp (matsulab.is.titech.ac.jp [131.112.35.129]) by hub.freebsd.org (Postfix) with ESMTP id BFD2537B403 for ; Wed, 29 Aug 2001 13:12:24 -0700 (PDT) (envelope-from fuyuhik8@is.titech.ac.jp) Received: from tripper.private by matsulab.is.titech.ac.jp (8.8.8+Sun/3.7W) id FAA07771; Thu, 30 Aug 2001 05:12:18 +0900 (JST) Date: Thu, 30 Aug 2001 05:14:47 +0900 Message-ID: <55heuqipxk.wl@tripper.private> From: Fuyuhiko Maruyama To: Daniel Eischen Cc: Fuyuhiko Maruyama , hackers@FreeBSD.ORG Subject: Re: libc_r, signals and modifying sigcontext In-Reply-To: References: <55k7zmiwop.wl@tripper.private> User-Agent: Wanderlust/2.6.0 (Twist And Shout) on XEmacs/21.5.1 (anise) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII 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 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 > #include > #include > #include > > #ifdef _THREAD_SAFE > #include > #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 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