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:13:00 +0100
Cc: Kaz Kylheku <KKylheku@zeugmasystems.com>, linux-mips@linux-mips.org
In-reply-to: <4A415ACD.8010102@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <DDFD17CC94A9BD49A82147DDF7D545C501C35128@exchange.ZeugmaSystems.local> <4A415ACD.8010102@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Jun 23, 2009 at 03:44:29PM -0700, Kevin D. Kissell 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.

  Ralf

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