| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] Make Broadcom SoC naming options consistent, Ralf Baechle |
|---|---|
| Next by Date: | Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS., Ralf Baechle |
| Previous by Thread: | Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS., Kevin D. Kissell |
| Next by Thread: | Re: Silly 100% CPU behavior on a SIG_IGN-ored SIGBUS., Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |