linux-mips
[Top] [All Lists]

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

To: "Ralf Baechle" <ralf@linux-mips.org>, "Kevin D. Kissell" <kevink@paralogos.com>
Subject: RE: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.
From: "Kaz Kylheku" <KKylheku@zeugmasystems.com>
Date: Thu, 25 Jun 2009 09:00:19 -0700
Cc: <linux-mips@linux-mips.org>
In-reply-to: <20090625134511.GC10661@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: Acn1m1TTDKQ20u7fRq26aJyxWnJLXAADr/iQ
Thread-topic: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.
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.

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. 

<Prev in Thread] Current Thread [Next in Thread>