<div dir="ltr">SIGUSR2 is used by the hotspot, internally, to implement suspend/resume. It gets sent by hotspot via pthread_kill() to targeted threads to suspend them. In that case it is known that the receiving thread is a valid java thread and therefore the assert makes sense.<div><br></div><div>However, as you describe SIGUSR2 can also be sent from outside via kill(2). In that case the receiving thread is arbitrarily chosen by the kernel. It is not necessarily a valid java thread. In that case the VM will crash (release) or assert (debug).</div><div><br></div><div>I tend to think this is an error too. Or at least in grey area. Since this is very easy to fix in the hotspot, I'd suggest we do this.</div><div><br></div><div>If nobody objects, I can file an issue and prepare the patch.</div><div><br></div><div>Cheers, Thomas</div><div><br></div><div>(P.s. not C++ undefined behavior, nothing to do with C++ :-)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov <<a href="mailto:turbanoff@gmail.com">turbanoff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I mean, isn't JVM supposed to be safe? :)<br>
Receiving this signal _could_ happen in a real deployment. And now, as<br>
I can see, we have C++ undefined behaviour in release builds in this<br>
case. Can we consider this as a bug?<br>
<br>
Andrey Turbanov<br>
<br>
вт, 14 июн. 2022 г. в 14:46, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>>:<br>
><br>
> On 14/06/2022 10:44, Andrey Turbanov wrote:<br>
> > Hello.<br>
> > During investigation of signal handling in JVM (for<br>
> > <a href="https://github.com/openjdk/jdk/pull/9100#discussion_r894992558" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/9100#discussion_r894992558</a> )<br>
> > I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)<br>
> ><br>
> > kill -USR2 1346792<br>
> ><br>
> > # assert(thread != __null) failed: Missing current thread in SR_handler<br>
> > # Internal Error<br>
> > (/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),<br>
> > pid=1346792, tid=1346792<br>
> ><br>
> > Full hs_err_pid1346792.log:<br>
> > <a href="https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a" rel="noreferrer" target="_blank">https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a</a><br>
> ><br>
> ><br>
> > Is it known/expected behaviour?<br>
> > I found some description there<br>
> > <a href="https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html" rel="noreferrer" target="_blank">https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html</a><br>
> > that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?<br>
><br>
> In general you have to be very careful when using signals. Yes, it can<br>
> easily break things and probably notice it quickly with debug builds as<br>
> asserts are compiled in to the builds (like the above). So I think<br>
> you've found the right page to read up on this. In this case, you can<br>
> set _JAVA_SR_SIGNUM to specify a different signal for S/R.<br>
><br>
> -Alan<br>
</blockquote></div>