<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed 15. Jun 2022 at 15:06, David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 15/06/2022 8:45 pm, Thomas Stüfe wrote:<br>
> More specifically, I propose to gracefully ignore SIGUSR2 in release <br>
> builds if the receiving thread is not a java thread, but to retain the <br>
> assert in debug builds.<br>
> <br>
> We could make it more involved by checking the sender pid and accepting <br>
> only signals from hotspot threads themselves, but I do not think this <br>
> complexity is necessary.<br>
<br>
Nor do I. SIGUSR2 is reserved for use by the VM and we document that. If <br>
you start throwing around random signals at processes then they can <br>
crash - so don't do that. I'm not sure ignoring signals that shouldn't <br>
be raised actually aids the end-user who obviously has an issue in their <br>
environment that needs to be addressed.</blockquote><div dir="auto"><br></div><div dir="auto">I see your point. I dislike crashes, especially ones they can be reliably triggered from outside. You never can be sure about the security implications either.</div><div dir="auto"><br></div><div dir="auto">If you dislike ignoring the signal, and since the default action for SIGUSR1+2 is process termination, why not exit the VM with an error message instead? At least we don’t have what looks like a random segfault, and we could print out the sender pid too.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
> I mean, isn't JVM supposed to be safe? :)<br>
<br>
Not when it comes to native code and signals - there it is more a case <br>
of caveat emptor.<br>
<br>
Cheers,<br>
David<br>
-----<br>
<br>
> Cheers, Thomas<br>
> <br>
> On Wed, Jun 15, 2022 at 12:26 PM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a> <br>
> <mailto:<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>>> wrote:<br>
> <br>
> SIGUSR2 is used by the hotspot, internally, to implement<br>
> suspend/resume. It gets sent by hotspot via pthread_kill() to<br>
> targeted threads to suspend them. In that case it is known that the<br>
> receiving thread is a valid java thread and therefore the assert<br>
> makes sense.<br>
> <br>
> However, as you describe SIGUSR2 can also be sent from outside via<br>
> kill(2). In that case the receiving thread is arbitrarily chosen by<br>
> the kernel. It is not necessarily a valid java thread. In that case<br>
> the VM will crash (release) or assert (debug).<br>
> <br>
> I tend to think this is an error too. Or at least in grey area.<br>
> Since this is very easy to fix in the hotspot, I'd suggest we do this.<br>
> <br>
> If nobody objects, I can file an issue and prepare the patch.<br>
> <br>
> Cheers, Thomas<br>
> <br>
> (P.s. not C++ undefined behavior, nothing to do with C++ :-)<br>
> <br>
> On Wed, Jun 15, 2022 at 12:11 PM Andrey Turbanov<br>
> <<a href="mailto:turbanoff@gmail.com" target="_blank">turbanoff@gmail.com</a> <mailto:<a href="mailto:turbanoff@gmail.com" target="_blank">turbanoff@gmail.com</a>>> wrote:<br>
> <br>
> I mean, isn't JVM supposed to be safe? :)<br>
> Receiving this signal _could_ happen in a real deployment. And<br>
> 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<br>
> <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a> <mailto:<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>
> > ><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>
> <<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<br>
> fastdebug x64)<br>
> > ><br>
> > > kill -USR2 1346792<br>
> > ><br>
> > > # assert(thread != __null) failed: Missing current thread<br>
> in SR_handler<br>
> > > # Internal Error<br>
> > ><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>
> > ><br>
> <a href="https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a" rel="noreferrer" target="_blank">https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a</a><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>
> > ><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>
> <<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<br>
> Hotspot?<br>
> ><br>
> > In general you have to be very careful when using signals.<br>
> Yes, it can<br>
> > easily break things and probably notice it quickly with debug<br>
> builds as<br>
> > asserts are compiled in to the builds (like the above). So I<br>
> think<br>
> > you've found the right page to read up on this. In this case,<br>
> you can<br>
> > set _JAVA_SR_SIGNUM to specify a different signal for S/R.<br>
> ><br>
> > -Alan<br>
> <br>
</blockquote></div></div>