Linux signals

Walt Drummond walt at drummond.us
Sat Jan 9 21:10:57 UTC 2021


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.

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
> >>>


More information about the hotspot-dev mailing list