RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside

Thomas Stuefe stuefe at openjdk.org
Mon Jun 20 08:05:55 UTC 2022


On Mon, 20 Jun 2022 07:35:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> Okay I see SIGUSR2 (or more generally SR_SIGNUM) is special in that regard: it is an internal-use-only non-terminating signal. But any external sending of SIGUSR2 is invalid regardless of whether an attached or not-attached thread handles it.

So, should I fail if si_pid!=getpid? As I wrote, I was a bit worried that some OSes may not deliver the correct pid in si_pid - either deliver the kernel thread id or leave it empty. I have dim recollections of such errors on AIX or HPUX. So far, we use si_pid only for displaying purposes and don't really rely on it being correct.

Another issue, I tried the patch with redefining SR_SIGNUM and found that I could not use SIGUSR1 on Linux because its numerical value (10) is below SIGSEGV(11) on my box and we have this code:

https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0a5f5770612cd8523ff0c16b240faf8498b94043/src/hotspot/os/posix/signals_posix.cpp*L1684-L1689__;Iw!!ACWV5N9M2RV99hQ!Ihm8CFH8kEeicajmh-yt1SPmh_STLxiHXl56_91fA1VbTrPX3W9vlyxoKEiXJL0HY_JEKkCo5plteewO5PmRc3NerXYz$ 

Do you think this is fix-worthy? SIGUSR1 seems an obvious choice for an alternate SR signal, but OTOH nobody complained in 20+ years.

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

PR: https://git.openjdk.org/jdk/pull/9181


More information about the hotspot-runtime-dev mailing list