Well it's not a patch yet! Because I might be wrong! And I am not an official developer.
Note that I have checked also the source code of the official snapshot as released by both Oracle and OpenJDK and Oracle snapshot files source code related to the issue is the same. The shared library libjsig.so is implemented in file jsig.c. Now when the function -- sighandler_t signal(int signum, sighandler_t handler) -- overidden in jsig.c is called by the process it will fall through the function -- static void save_signal_handler(int sig, sa_handler_t disp) -- implemented in file jsig.c to save the signal settings.This will be further chained by Java if the JVM finds its doesn't own the signal when the Java signal handler is called. This chaining is done with these steps : 1- When JVM finds that it doesn't own the signal it call -- bool os::Linux::chained_handler(int sig, siginfo_t* siginfo, void* context) in file os_linux.cpp 2- Then JVM call -- struct sigaction* os::Linux::get_chained_signal_action(int sig) -- to retrieve the saved signal parameter through calling function -- struct sigaction *JVM_get_signal_action(int sig) -- of shared library libsig.so 3- Next JVM call -- bool call_chained_handler(struct sigaction *actp, int sig, siginfo_t *siginfo, void *context) with the retrieved signal parameter. Inside the function -- call_chained_handler -- the JVM checks if the signal handler is of type sa_handler_t in which case it will call the sa_handler defined in the retrieved parameters from function -- JVM_get_signal_action. However there is the issue. Before calling the sa_handler it will reconfigure the signal mask with function -- pthread_sigmask -- with the saved mask from the retrieved parameters. Doing this for a signal handler defined as sa_sigaction_t type is fine since the stored parameters has the a-priori knowledge of the mask requested when calling the sa_sigaction. But doing it for a signal handler of type sa_handler is wrong. The chained saved parameters by jsig.c for signal handler of type sa_handler is set to an all empty mask using the function -- sigemptyset(&set) -- when the parameters are saved by function -- void save_signal_handler(int sig, sa_handler_t disp, bool is_sigset) -- It is my understanding that when a signal of type sa_handler is chained no assumption can be made about having to reprogram the thread mask unless the signal and the context can provide this information. Thus I believe the pthread mask should stay like it was when the signal is chained and not set to an all empty mask. Please comment! GB ________________________________________ From: Dr Andrew John Hughes [ahug...@redhat.com] Sent: Wednesday, May 04, 2011 5:37 PM To: BONNEAU Guy Cc: jdk6-dev@openjdk.java.net Subject: Re: Issue chaining signal exception On 20:10 Wed 04 May , BONNEAU Guy wrote: > I downloaded the source code from a snapshot of the URL > > http://download.java.net/openjdk/jdk6/ > > Thanks > GB > ________________________________________ That's fine. Feel free to post your patch here. I just had to check as Oracle have lots of JDK source code floating around, some of which is under a proprietary license. The above is OpenJDK6 and so fine. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
