RFR(XXS): 8007312: Signal Dispatcher thread to start and register	ctrl-break handler before TRACE_INITIALIZE
    Markus Grönlund 
    markus.gronlund at oracle.com
       
    Thu Jan 31 13:22:58 PST 2013
    
    
  
Greetings,
 
Can I kindly ask for a few reviews and a putback sponsorship for the following change:
 
Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312
Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/
Hotspot JPRT builds/tests : completed successfully
 
Comment on issue/fix:
 
(windows analysis)
 
Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. 
 
Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables.
 
// on Windows this creates the following issue when closing a NULL handle to a  semaphore
 
void os::signal_notify(int signal_number) {
  BOOL ret;
 
  Atomic::inc(&pending_signals[signal_number]); 
  ret = ::ReleaseSemaphore(sig_sem, 1, NULL);   <<--- call ReleaseSemaphore on global handle sig_sem which has not been setup/created yet == is NULL (is created in os::signal_init_pd())
  assert(ret != 0, "ReleaseSemaphore() failed"); <<-- assert traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) 
  
}
 
The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup.
 
Thanks
Markus
    
    
More information about the hotspot-dev
mailing list