Shane McDonald wrote:
Hi Kevin:
On Mon, May 3, 2010 at 2:47 PM, Kevin D. Kissell <kevink@xxxxxxxxxxxxx> 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.
Regards,
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)
Regards,
Kevin K.
