Linux signals

[Walt Drummond]

Hi David --

Sorry, I've come to appreciate the confusion this causes; I can't tell
if by 'thread' you mean a java thread or a POSIX thread. :)  To help
punch through some of that, I'm going to be a bit pedantic, apologies
in advance.

When the kernel delivers a signal to a process/thread (in the Linux
sense of the term), it places some data on the process stack.  That
data includes the parameters to the POSIX signal hander (signal
number, a siginfo_t, and a ucontext_t).  Above that in the stack, the
kernel also places FPU state and, on AMD64, extended state
information.  My question is does the JVM directly inspect the JVM
program stack when running the POSIX signal handler(s).  My current
understanding is that it does not and only relies on the POSIX signals
APIs and data structures from libc.

Thanks, and sorry for the confusion.

On Thu, Jan 7, 2021 at 8:30 PM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Walt,
>
> On 8/01/2021 7:18 am, Walt Drummond wrote:
> > Hi --
> >
> > I'm chasing down some information about how the JVM interacts with
> > signals on Linux.  Specifically I need to understand if any of the
> > Java runtime attempts to directly inspect the system stack when in a
> > POSIX signal handler.  My survey of the code doesn't seem to show any
> > such uses, and in fact it looks like the JVM relies only on the POSIX
> > signals API but I figured I'd ask the experts for confirmation.
>
> I'm not quite sure what you are asking with regards to the "system
> stack". The hotspot signal handler does a range of things to try and
> determine what the signal might mean - e.g. whether it is a true error
> or an internal use of signals that we can recover from. That may involve
> examining the thread stack.
>
> Cheers,
> David
> -----
>
> > Thanks.
> > --Walt
> >