RFR: 8283337: Posix signal handler modification warning triggering incorrectly

[Thomas Stuefe]

On Fri, 18 Mar 2022 11:05:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 
> Not sure about removing do_check_signal_periodically ? It still checks the others handlers, even if vm_handlers.get(SIGBREAK) returns null.

I was under assumption that do_check_signal_periodically[] = true and vm_handlers.get() != NULL mean the same. But I see now there are subtle differences: when Xcheck:jni encounters a mismatch, it prints out a warning, and then disables the check by setting do_check_signal_periodically[] = false. But it leaves vm_handlers intentionally unchanged, so in the hs-err file we still get noticed about the changed handler. That way we have a warning on stdout, and one in the hs-err file.

So please ignore my proposal about removing do_check_signal_periodically.

> 
> Ideally yes we would save the second SIGQUIT handler - I think the problem there is that it is set later by os::signal() which doesn't have a way to distinguish itself from any other native code setting a handler. It is the kind of signal action setting code which this saved handler mechanism is trying to notice (and it does notice it!)

I wondered about that too. The question is whether its valid to repurpose hotspot signals when done via the official java API. And while I think about this, probably not. You are right, a blanket "ok" for os::signal() would be wrong.

We could just try and handle SIGQUIT differently. But everything I can come up quickly is hacky. E.g. treat the first modification of SIGQUIT via java special. But oh god thats ugly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7858