<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>> ><br>
> > I see your point. I dislike crashes, especially ones they can be<br>
> > reliably triggered from outside. You never can be sure about the<br>
> > security implications either.<br>
> ><br>
> > If you dislike ignoring the signal, and since the default action for<br>
> > SIGUSR1+2 is process termination, why not exit the VM with an error<br>
> > message instead? At least we don’t have what looks like a random<br>
> > segfault, and we could print out the sender pid  too.<br>
><br>
> We could ... but then do we do that for every other signal that can be<br>
> thrown at the JVM from externally and which will leads to crashes? Where<br>
> do you stop?<br>
<br></blockquote><div><br></div><div>It's a very limited set. I'd say we limit this to </div><div><br></div><div>1) signal for which we registered handlers: the handlers should at least not crash or vanish the VM without a trace<br></div><div>2) signals which may conceivably be sent to the VM in the normal course of events: if the default action is to terminate the VM, we should handle them</div><div><br></div><div>Note that for (2), we already do this for some signals. We explicitly handle SIGPIPE (<a href="https://bugs.openjdk.org/browse/JDK-4229104">https://bugs.openjdk.org/browse/JDK-4229104</a>) and SIGXFSZ (<a href="https://bugs.openjdk.org/browse/JDK-6499219">https://bugs.openjdk.org/browse/JDK-6499219</a>) because they kill the VM. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Well, playing devil's advocate, why not? Would it be more complex than adding a<br>
<br>
    if (si.si_pid != my_cached_pid) {<br>
        // it came from Outside, let's exit with 128+signum<br>
        // ...<br>
    }<br>
<br>
to the top of the signal handler(s)?<br>
<br>
-- <br>
- DML • he/him<br>
<br></blockquote><div><br></div><div>I filed a JBS issue and a PR: <a href="https://github.com/openjdk/jdk/pull/9181#issuecomment-1157353776">https://github.com/openjdk/jdk/pull/9181#issuecomment-1157353776</a>. </div><div><br></div><div>I went with a different approach, just using Thread::current=NULL as an indicator. I was worried that Unix implementations may leave the si_pid field empty, or that it gets filled with the sender's kernel thread id, not the process pid. Just verified that on Linux, its really actually the process id (so the main threads id). <br></div><div><br></div><div>Cheers, Thomas</div></div></div>