linux-mips
[Top] [All Lists]

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

To: "Kevin D. Kissell" <kevink@paralogos.com>
Subject: Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS.
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 25 Jun 2009 14:45:11 +0100
Cc: Kaz Kylheku <KKylheku@zeugmasystems.com>, linux-mips@linux-mips.org
In-reply-to: <20090625131300.GB10661@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <DDFD17CC94A9BD49A82147DDF7D545C501C35128@exchange.ZeugmaSystems.local> <4A415ACD.8010102@paralogos.com> <20090625131300.GB10661@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Jun 25, 2009 at 02:13:00PM +0100, Ralf Baechle wrote:

> >> int main(void)
> >> {
> >>   int *deadbeef = (int *) 0xdeadbeef;
> >>   signal(SIGBUS, SIG_IGN);
> >>   printf("*deadbeef == %d\n", *deadbeef);
> >>   return 0;
> >> }
> >>
> >> If any fatal exception is ignored, the program should be killed
> >> if that exception happens. 100% CPU is not a useful response.
> >>   
> > It's not a useful program, so what did you expect?   One might argue  
> > that it would be more useful or correct to have the kernel advance the  
> > PC to not endlessly repeat the doomed load, but ignoring SIG_IGN and  
> > silently killing the thread violates the signal API as I've always  
> > understood it.
> 
> It's not a useful program but valid as a test case.  However I agree with
> your interpretation of signal semantics but I'll have to round up a copy
> of the relevant standard documents; I have vague memories about some small
> print for cases like this.

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. 

  Ralf

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