JDK-6318988 : -Xcheck:jni support for user defined Signal handlers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-01
  • Updated: 2015-11-17
  • Resolved: 2007-01-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Description
There are customers who use native subsystems using JNI. Some of these subsystems use signal handlers for their own memory management. Though it is documented on how to use the libjsig.so, to debug a complicated application is not very easy if there is an user error. We must provided better diagnostics and checks something like Xcheck:jni to trace the installation of signal handlers.
Thus we should:
1. Provide a VM launcher flag to specify LD_PRELOAD vs. the environment variable. So customers have
complicated startup scripts which overwrite environment variables.

2. Provide a mechanism like -Xcheck:signal to trace signal handler interpositions etc.
Comments
SUGGESTED FIX See the attachments for the webrev on the proposed solution.
07-11-2006
EVALUATION The hs_err log file as of 1.6 contains info if the Signal Handlers have been hijacked, however when the signal handlers are taken over by the JNI application depending on how the users handlers work we might not even get a hs_err.log file. The solution here is to use the watcher thread undex -Xcheck:jni to periodically checked if the Signal handlers has been usurped.
07-11-2006