RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM (original) (raw)
Dmitry Samersoff dmitry.samersoff at oracle.com
Thu Nov 12 09:05:10 UTC 2015
- Previous message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Next message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Goetz,
*BSD including OS X also defines NSIG (just checked) and if my memory is not bogus, AIX defines it too.
So you may consider to use NSIG on all platform.
-Dmitry
On 2015-11-12 11:36, Lindenmaier, Goetz wrote:
OK I'll change it to NSIG. That's used in other places in oslinux, too. So it's really more consistent.
Best regards, Goetz
-----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Donnerstag, 12. November 2015 09:22 To: David Holmes; Lindenmaier, Goetz; hotspot-runtime- dev at openjdk.java.net; serviceability-dev Subject: Re: RFR(M): 8141529: Fix handling of JAVASRSIGNUM
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 * I would love to change the world, but they won't give me the sources.
-- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia
- I would love to change the world, but they won't give me the sources.
- Previous message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Next message: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]