SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal, and backward compatibility

Tue Nov 3 05:42:19 UTC 2020

Hi David,

On Tue, Nov 3, 2020 at 4:27 AM David Holmes <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 2/11/2020 5:40 pm, Thomas Stüfe wrote:
> > Hi,
> >
> > While working on some signal handler fixes and cleanups ([1]), I noticed
> > that we export JVM_handle_(linux|bsd)_signal() on all POSIX platforms.
> >
> > I wondered why we do this. See also my first question at runtime-dev [2]
> -
> > the initial reaction was "probably no reason anymore".
> >
> > But then, I see a carefully crafted comment in [3]:
> >
> > <quote>
> > // This routine may be used by user applications as a "hook" to catch
> > signals.
> > // The user-defined signal handler must pass unrecognized signals to this
> > // routine
> > ...
> > </quote>
> >
> > and I also found some bug reports [4], [5], from 2001 and 2004:
> > JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
> > JDK-4408646 : "JVM_handle_solaris_signal must be a global function"
> >
> > So, to me this looks like JVM_handle_xxx_signals() was an official, or at
> > least deliberate, interface for foreign code to interact with our signal
> > handling. Specifically, this reads like a third party could install its
> > signal handlers over ours, and as long as it queried our signal handler
> > first by calling JVM_handle_xxx_signal(), we still could coexist with it.
>
> Did you see this comment:
>
>
> https://bugs.openjdk.java.net/browse/JDK-4361067?focusedCommentId=12425956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12425956
>
> This is tied to AllowUserSignalHandlers so we'd have to go through the
> deprecation process to make any changes in this area.
>
>
Excellent point. Thanks for digging that up. Would love to know who wrote
this code + comment.

(Note that I believe this comment uses the term "signal chaining" to
describe a general concept, not the solution implemented in hotspot today
via the UseSignalChaining + libjsig).

Looked at this and a cursory glance through github sources shows that this
flag is used quite a lot, and I think it is useful too (I remember Florian
Weimers question about it here:
https://mail.openjdk.java.net/pipermail/discuss/2019-April/005046.html -
and this is exactly the answer, this would be the alternative).

But man, this raises so many questions. I see that AllowUserSignalHandlers
had been implemented by just refusing to install the central hotspot signal
handler. But it's not honored for the installation of the SR handler, nor
for anything which gets installed via os::signal(). So we have bitrot right
there already. Then, it never can have worked on AIX since we have a day
zero bug in our port. And so on...

> > But now we have signal chaining [6], which achieves the same by
> preloading
> > the libjsig library. Which some consider to be ewww [7] :-), but still
> > seems to me like the official solution to that problem. Using signal
> > chaining there would be no need to manually call JVM_handle_xxx_signal()
> > from outside since the interposed sigaction() in libjsig would take care
> of
> > all this stuff automatically.
>
> Aren't the two mechanisms complementary in that they work in opposite
> ways? Signal chaining keeps the VM in control and allows it to call
> application handlers.  AllowUserSignalHandlers keeps the app in control
> and requires it to call VM handlers.
>

I don't believe so. I do not have the means to check it, but would not be
surprised if signal chaining was actually the later invention.

We have three mechanisms:
A) AllowUserSignalHandlers, which just refuses to install signal handlers
(thereby effectively disabling UseSignalChaining), but user handler needs
to call our handler
B) UseSignalChaining, which handles the case where we come after the user
handler - we install our handlers, but remember the user handler and later
invoke it
C) libjsig interposition, which handles the case where the user handler
gets installed over our handler - libjsig prevents this and we end up with
the same signal handler chain as in (B)

(B) and (C) (together termed "signal chaining" now) are a complete
replacement for (A). (A) is somewhat simpler, especially with the
interposition stuff, and gives the user handler more control, since it can
decide to handle signals before we get to see them. Whether or not that's
wise is another thing.

Very probably (A) should not be used together with (C) or (B).

> > My question is:
> > - if JVM_handle_xxx_signal() is (had been?) an official interface, should
> > there not be some official documentation and regression tests? Was
> there? I
> > could not find anything.
> > - if it is not an official interface, would it be okay to lay it to rest?
> >    - Pro: it is made obsolete by signal chaining, and removing it would
> > reduce complexity of signal handling somewhat
> >    - Con: applications may exist out there which use that interface, and
> I'd
> > hate to break them. We give customers enough reasons to cling to old JDK
> > versions as it is.
> >       Also, arguably, this interface is useful. Not everyone likes
> > preloading libjsig, and the signal chaining mechanism is also a whole lot
> > more fragile.
> >
> > However, if we let it live on, should we not document and test it?
>
> It is not well documented that is for sure.
>
> Not sure about testing ... I tend to see this more a "best effort"
> mechanism. If someone reports it stops working, or doesn't work, then
> we'll make a best effort to fix it.
>

If it is "best effort", can I just stub them out and let them return 0
always then?
:-) Just kidding. This is the same argument as in "int random()  { return
0; } is technically valid".

But seriously, tests would give me some measure of safety while working
with this code, as well as preventing bitrot or accidental removal. Just
look at the people queuing up to change or remove those handlers - see e.g.
https://github.com/openjdk/jdk/pull/636.

> > I am really interested in the history of this. Was this just a solution
> for
> > a single customer?
>
> Not sure of specific details but it was for hosting the VM in native
> applications that already did their own signal management.
>
> Cheers,
> David
>
>
Thanks for the infos!

..Thomas

> >
> > Thanks, Thomas
> >
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8255711
> > [2]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
> > [3]
> >
> https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
> > [4] https://bugs.openjdk.java.net/browse/JDK-4864136
> > [5] https://bugs.openjdk.java.net/browse/JDK-4408646
> > [6]
> >
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> > [7]
> https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html
> >
>