RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v3]

[Gerard Ziemski]

On Mon, 28 Dec 2020 07:52:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI.
>> 
>> Before:
>> Signal Handlers:
>> SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>> 
>> Now:
>> Signal Handlers:
>>    SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>     SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>     SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>     SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO
>>     SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>     SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO
>>    SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none
>> 
>> The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. 
>> 
>> It also introduces gtests for that function. 
>> 
>> I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE.
>
> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - style changes
>  - Fix Windows gtests

Marked as reviewed by gziemski (Committer).

src/hotspot/share/runtime/os.cpp line 896:

> 894:   char* p = buf;
> 895:   if (p == NULL) {
> 896:     p = (char*)::alloca(O_BUFLEN);

You have raised the issue of whether using `alloca(O_BUFLEN )` is a good choice elsewhere in the review, so I just wanted to quickly touch on that.

O_BUFLEN being 2000 bytes doesn't seem to be a big deal, still would using static array here instead be a better choice?

What happens if our signal handler is handling stack overflow error?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1839