[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Issue chaining exception
From:       gbonneau () miranda ! com (BONNEAU Guy)
Date:       2011-05-09 13:58:48
Message-ID: 24665DDC0D7CF047BD6471A56E615EA628ABCA18 () CA-OPS-MAILBOX ! miranda ! com
[Download RAW message or body]

I have posted on the JDK DEV email list what I think might be an issue with signal \
chaining of the JVM. However I have been told this list is better fit for issue about \
libjsig.so. I am looking for comment.



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 seems to be \
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110509/99041460/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]