Ralf Baechle wrote:
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.
It is kind of moot at this point. The HEAD now kills the process
instead of looping forever.
David Daney
