linux-mips
[Top] [All Lists]

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

To: Kaz Kylheku <KKylheku@zeugmasystems.com>
Subject: Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 26 Jun 2009 01:45:27 +0100
Cc: "Kevin D. Kissell" <kevink@paralogos.com>, linux-mips@linux-mips.org
In-reply-to: <DDFD17CC94A9BD49A82147DDF7D545C501C35485@exchange.ZeugmaSystems.local>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090625134511.GC10661@linux-mips.org> <DDFD17CC94A9BD49A82147DDF7D545C501C35485@exchange.ZeugmaSystems.local>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
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

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