Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Jun 25, 2009 at 09:00:19AM -0700, Kaz Kylheku wrote:

> Ralf wrote:
> > I found this in IRIX 6.5 documentation:
> > 
> >   Caution: Signals raised by the instruction stream, SIGILL, 
> >   SIGEMT, SIGBUS, and SIGSEGV, will cause infinite loops
> >   if their handler returns, or the action is set to SIG_IGN. 
> 
> The Single Unix Specification (Issue 6) marks the behavior
> explicitly undefined.

I should have mentioned that above mentioned paragraph of IRIX documentation
was in the section on implmentation specific behaviour.

> Bookmark this: http://www.opengroup.org/onlinepubs/009695399
> 
> Not the latest set of documents, but that can be regarded
> as a virtue. :)
> 
> Under pthread_sigmask and sigprocmask, for blocking:
> 
>   If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS
>   signals are generated while they are blocked,
>   the result is undefined, unless the signal
>   was generated by the kill() function, the
>   sigqueue() function, or the raise() function.
> 
> Under ``2.4 Signal Concepts'', for SIG_IGN:
> 
>   SIG_IGN 
> 
>   Ignore signal. 
> 
>   Delivery of the signal shall have no effect on
>   the process. The behavior of a process is undefined
>   after it ignores a   SIGFPE, SIGILL, SIGSEGV,
>   or SIGBUS  signal that was not generated by kill(),
>   sigqueue(), or raise().
> 
> So, as I suspected, there are in fact no requirements
> from the applicable spec. Infinite looping or
> stopping the process anyway are conforming responses,
> as is rebooting or halting the machine with a
> ``panic'' message. 

I'd not go quite as far as that but execve("/usr/bin/nethack") certainly
would be acceptable.

  Ralf