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
|