JDK-8007312 : null check signal semaphore in os::signal_notify windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-01-31
  • Updated: 2013-06-26
  • Resolved: 2013-02-13
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
tracing adds to the startup of the vm, if a user presses ctrl-c during that initialization, the signal dispatcher thread and the ctrl-break handler is not yet setup.

On windows, this asserts on debug builds:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\os_windows.cpp:1963
# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (..\..\src\os\windows\vm\os_windows.cpp:1963), pid=612, tid=35
#  assert(ret != 0) failed: ReleaseSemaphore() failed
# JRE version: Java(TM) SE Runtime Environment (7.0_14) (build 1.7.0_14-ea-n
# Java VM: Java HotSpot(TM) Server VM (24.0-b32-internal-debug mixed mode window
s-x86 )
# Failed to write core dump. Minidumps are not enabled by default on client vers
ions of Windows
# An error report file with more information is saved as:
# D:\temp\SPECjbb2005_kitv1.07\SPECjbb2005\hs_err_pid612.log
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp

The ReleaseSemaphore is performed on an non-initialized global Handle, this causes the assert to trap

The UserHandler() signal handler is installed via Terminator.setup() during Threads::create_vm call_initializeSystemClass() . This causes us to end up in os::signal_notify() even though the signalling subsystem is not yet setup. Do explicit initialization check on sig_sem before calling ::ReleaseSemaphore on Windows.

suggest to remove the asserts in os::signal_notify() for solaris and windows (no asserts exist on bsd and linux) - behaviour is more in line with product builds

There are probably a few windows during startup where ctrl-c can't work correctly. Be cautious about simply changing the initialization sequence - move TRACE_INITIALIZE if possible rather than the starting of the signal dispatcher thread. The initialization sequence is fragile and most issues don't become apparent until using specific VM flags with specific features on a specific VM (ie fastdebug).

Fix in progress