Linux signals

[Walt Drummond]

Thank you.  Appreciate it.

On Sat, Jan 9, 2021 at 3:44 PM David Holmes <david.holmes at oracle.com> wrote:
>
> On 10/01/2021 7:10 am, Walt Drummond wrote:
> > Context: I'm chasing down concerns that increasing the size of the
> > kernel's definition of sigset_t would break userspace.  This only
> > seems plausible if (1) on receipt of a signal user space tries to
> > unwind or directly interpret the program stack frame or (2) the
> > application uses a definition of sigset_t that is not derived from
> > glibc.  From what I see here, neither of these are the case. The JVM
> > inspects the state of the stack by looking at the ucontext_t structure
> > passed to it from the kernel and it exclusively uses the POSIX signals
> > APIs and the system libc.
>
> Thanks for the info. I think we should be all good on that front.
>
> David
>
> > On Sat, Jan 9, 2021 at 5:10 AM David Holmes <david.holmes at oracle.com> wrote:
> >>
> >> Hi Walt,
> >>
> >> On 9/01/2021 2:22 am, Walt Drummond wrote:
> >>> 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.
> >>
> >> In hotspot there is a 1:1 correspondence between a Java thread and
> >> OS/Posix thread.
> >>
> >>> 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.
> >>
> >> As I stated before the JVM signal handler may inspect the stack, or it
> >> may not, depending on the nature of the signal it is processing - crash
> >> reporting can do a lot of things from the signal handler. You can see
> >> the main signal handler here:
> >>
> >> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525
> >>
> >> What is the context for asking the question?
> >>
> >> Cheers,
> >> David
> >> -----
> >>
> >>
> >>> 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
> >>>>>