[Top] [All Lists]

Re: Unexpected behaviour when catching SIGFPE on FPU-less system

To: Shane McDonald <>
Subject: Re: Unexpected behaviour when catching SIGFPE on FPU-less system
From: "Kevin D. Kissell" <>
Date: Mon, 03 May 2010 19:04:02 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=woJOuJBQaK+J8aUq0puw0ZRYAFcHkF3lC9LNLJkbza8f8VlU2oAe2juzIsZRS2nZv/dBxDPZPqnMwx3OkYEXR0WL2+aADzC2CJuimEGiFr8lSQVw/iOV2vuueHnELRAy;
In-reply-to: <>
Original-recipient: rfc822;
References: <E1O8lDn-0000Sk-86@localhost> <> <>
User-agent: Thunderbird (X11/20100317)
Shane McDonald wrote:
Hi Kevin:

On Mon, May 3, 2010 at 2:47 PM, Kevin D. Kissell <> wrote:
Sorry about my previous message having escaped with no value added.

I think you need to look at just what it is that your feclearexcept() does.
 From the strace information, it looks as if it may be that the FPU emulator
is erroneously throwing an exception in response to some manipulation of the
emulated FPU registers by feclearexcept(), so that it's taking a second FP
exception within the signal handler.  That's the simplest explanation for
the macroscopic behavior, anyway.


        Kevin K.

Commenting out the feclearexcept() line gives the same result:

     old_mmap(NULL, 65536, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ace9000
     write(1, "About to try calculation\n"..., 25About to try calculation
     ) = 25
     --- SIGFPE (Floating point exception) @ 0 (0) ---
     --- SIGFPE (Floating point exception) @ 0 (0) ---
     +++ killed by SIGFPE +++

So, it must not be the feclearexcept() causing the problem.
Well, that nested floating point exception must be coming from *somewhere*. If it's not library code being betrayed by the emulator, perhaps some kernel-mode code is being invoked which is carelessly assuming the existence of a hardware FPU and throwing us back into the exception handler. If it was me, at this point, I'd turn on some kind of logging of FP exception PCs to see where that second one is coming from.

There was a time when I had the necessary equipment on my desk to hunt this down and kill it, out of a lingering sense of responsibility for having bolted that FPE into the kernel way back when. I no longer have that setup, so I'm free to speculate. ;o)


         Kevin K.

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