RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM (original) (raw)

Dmitry Samersoff dmitry.samersoff at oracle.com
Thu Nov 12 08:22:01 UTC 2015

David,

I think it's better to use NSIG (without underscore) defined in signal.h

-Dmitry

On 2015-11-12 10:35, David Holmes wrote:

Hi Goetz,

Adding in serviceability-dev On 9/11/2015 6:22 PM, Lindenmaier, Goetz wrote: Hi,

The environment variable JAVASRSIGNUM can be set to a signal number do be used by the JVM's suspend/resume mechanism. If set, a signal handler is installed and the current signal handler is saved to an array. On linux, this array had size MAXSIGNUM=32, and JAVASRSIGNUM was allowed to range up to NSIG=65. This could cause memory corruption. Further, in jsig.c, an unsinged int is used to set a bit for signals. This also is too small, as only 32 signals can be supported. Further, the signals are mapped wrong to these bits. '0' is not a valid signal, but '32' was. 1<<32 happens to map to zero, so the signal could be stored, but this probably was not intended that way. This change increases MAXSIGNUM to 65 on linux, and to 64 on aix. It introduces proper checking of the signal read from the env var, and issues a warning if it does not use the signal set. It adapts the data types in jisig.c properly. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.00 This all sounds very good to me. (I must find out why Solaris is not involved here :) ). On Linux you didn't add the bounds check to os::Linux::setoursigflags. I'm also wondering about documenting where we are determining the maximum from? Is it simply NSIG on some/all distributions? And I see NSIG is supposed to be the biggest signal number + one. Also linux defines NSIG = NSIG so which should we be using? Thanks, David Best regards, Goetz.

-- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia

More information about the hotspot-runtime-dev mailing list