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