RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM (original) (raw)
Lindenmaier, Goetz goetz.lindenmaier at sap.com
Mon Nov 9 08:22:50 UTC 2015
- Previous message: RFR(S) 8139164: JVM should throw ClassFormatError for non-void methods named
- Next message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
The environment variable _JAVA_SR_SIGNUM 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 _JAVA_SR_SIGNUM 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
Best regards, Goetz.
- Previous message: RFR(S) 8139164: JVM should throw ClassFormatError for non-void methods named
- Next message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]