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