linux-mips
[Top] [All Lists]

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

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.
From: David Daney <ddaney@caviumnetworks.com>
Date: Thu, 25 Jun 2009 17:52:31 -0700
Cc: Kaz Kylheku <KKylheku@zeugmasystems.com>, "Kevin D. Kissell" <kevink@paralogos.com>, linux-mips@linux-mips.org
In-reply-to: <20090626004527.GA3235@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090625134511.GC10661@linux-mips.org> <DDFD17CC94A9BD49A82147DDF7D545C501C35485@exchange.ZeugmaSystems.local> <20090626004527.GA3235@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
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


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