On Thu, Jun 16, 2022 at 8:17 AM David Holmes <david.hol...@oracle.com> wrote:
> On 16/06/2022 12:09 am, Thomas Stüfe wrote:
> > On Wed 15. Jun 2022 at 15:06, David Holmes <david.hol...@oracle.com
> > <mailto:david.hol...@oracle.com>> wrote:
> > Nor do I. SIGUSR2 is reserved for use by the VM and we document
> > that. If
> > you start throwing around random signals at processes then they can
> > crash - so don't do that. I'm not sure ignoring signals that shouldn't
> > be raised actually aids the end-user who obviously has an issue in
> > their
> > environment that needs to be addressed.
> >
> >
> > 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.
> >
> > 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.
>
> We could ... but then do we do that for every other signal that can be
> thrown at the JVM from externally and which will leads to crashes? Where
> do you stop?
Well, playing devil's advocate, why not? Would it be more complex than adding a
if (si.si_pid != my_cached_pid) {
// it came from Outside, let's exit with 128+signum
// ...
}
to the top of the signal handler(s)?
--
- DML • he/him
