RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers
David Holmes
dholmes at openjdk.java.net
Mon Dec 21 09:15:56 UTC 2020
On Fri, 18 Dec 2020 10:10:13 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.
A minor comment, but otherwise this seems quite reasonable.
Thanks,
David
src/hotspot/os/posix/signals_posix.cpp line 1352:
> 1350: LINUX_ONLY(sa.sa_flags &= SA_RESTORER_FLAG_MASK;)
> 1351:
> 1352: st->print("%10s: ", os::exception_name(sig, buf, buflen));
Where does the 10 come from? Why do we need to limit it?
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1839
More information about the hotspot-runtime-dev
mailing list