illumos gate

Some fault conditions experienced by user programs are reported via signals, directed to the LWP which induced the fault. The list of such signals includes at least SIGSEGV, SIGBUS, SIGILL, SIGTRAP, and SIGFPE. When delivering a fault signal like this, we populate the siginfo_t with information about the fault address, and potentially the program counter, at the moment of the fault. In addition, some software (not unreasonably) will inspect the ucontext_t that we provide to the signal handler to collect more detailed information about the state of the program when it was interrupted by the signal. This is used by language runtimes like the JVM to convert a SIGSEGV into an appropriate NullPointerException, amongst other things.

When deciding which signal to deliver In issig_forreal(), we use fsig() twice: first, to check the thread-directed pending signal set; then, if there are no thread-directed signals, we check the process-directed signal set. In general, with a couple of exceptions, fsig() starts with the lowest numbered signal (i.e., it will try SIGBUS, 10, before SIGSEGV, 11).

The synchronous fault signals are all thread-directed, so they are given priority over any signals from outside. We do not, to my knowledge, allow processes to signal an arbitrary thread in another process -- they use kill(2), which only generates process-directed signals. Faulting signals, therefore, are effectively delivered first. The context we preserve from the interrupted program will reflect the machine state when the fault occurred.

Unfortunately, there are conditions under which an exception made in fsig() causes the incorrect behaviour. If SIGKILL is present in the inspected signal set, it will be prioritised above any other signal. That makes sense, because if KILL is asserted, the program is over before it gets to any other signal handling anyway. In addition to KILL, though, we give second place to SIGPROF (number 29!) before attending the rest of the signals in ascending order. When SIGPROF is process-directed, this doesn't matter because it falls in line behind any of the thread-directed fault signals. When using setitimer(2) with the ITIMER_PROF timer, however, the kernel _sends a thread-directed SIGPROF in clock_tick() if the LWP is on-CPU when the tick occurs!

This thread-directed SIGPROF will jump the queue to begin delivery prior to any fault signal that might have been tripped at around the time that the clock tick occurred. If the signal mask (sa_mask) provided to sigaction(2) for SIGPROF did not mask other signals, as soon as we unmask before calling the user handler, we'll be dragged back into the kernel to deliver the fault signal. We're now in nested signal handling territory, so the context we provide with that faulting signal reflects an interrupted libc signal handling function, not the user program.

A rough sequence of events that leads to the problem:

• user program asks for some unmapped memory
• page fault handler is triggered, determines the access is invalid, sets up a SIGSEGV for this LWP
• clock_tick() sends a thread-directed SIGPROF because we are presently on-CPU
• on the way back to user mode we see there are signals so we determine which one to send first; fsig() chooses the SIGPROF
• we return to user mode, vectored to the libc signal handling machinery, with all signals blocked and a context that refers to the main program that tripped the fault
• libc applies the sa_mask for our SIGPROF handler, unblocking signals by making a _lwp_sigmask() system call
• on return from _lwp_sigmask(), we see there are signals and fsig() tells us SIGSEGV is up next
• we are revectored to the SIGSEGV handler, with a context that refers to libc just after the _lwp_sigmask() call
• the user program's SIGSEGV handler flies off the rails because REG_PC doesn't point to the program text that faulted in the first place

Note that there is a wholly separate delivery mechanism for use of setitimer(2) with ITIMER_REALPROF which will also generate SIGPROF but not in this way, and does not appear to exhibit these same symptoms.

It seems reasonable not to prioritise SIGPROF before the synchronous fault signals (which are otherwise all lower in number than 29). Even if fsig() did nothing special with it, it will still be prioritised above signals from other processes by virtue of being thread-directed -- it just won't interfere with the correct delivery of context about SIGSEGV, SIGILL, etc.