Handling of USR2 signal in JVM on Linux

[Andrey Turbanov]

I mean, isn't JVM supposed to be safe? :)
Receiving this signal _could_ happen in a real deployment. And now, as
I can see, we have C++ undefined behaviour in release builds in this
case. Can we consider this as a bug?

Andrey Turbanov

вт, 14 июн. 2022 г. в 14:46, Alan Bateman <Alan.Bateman at oracle.com>:
>
> On 14/06/2022 10:44, Andrey Turbanov wrote:
> > Hello.
> > During investigation of signal handling in JVM (for
> > https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
> > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
> >
> > kill -USR2 1346792
> >
> > # assert(thread != __null) failed: Missing current thread in SR_handler
> > # Internal Error
> > (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
> > pid=1346792, tid=1346792
> >
> > Full hs_err_pid1346792.log:
> > https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a
> >
> >
> > Is it known/expected behaviour?
> > I found some description there
> > https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
> > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?
>
> In general you have to be very careful when using signals. Yes, it can
> easily break things and probably notice it quickly with debug builds as
> asserts are compiled in to the builds (like the above). So I think
> you've found the right page to read up on this. In this case, you can
> set _JAVA_SR_SIGNUM to specify a different signal for S/R.
>
> -Alan