On 2020-05-27 00:27 -0500, Bruce Dubbs write:
> On 5/26/20 11:43 PM, Xi Ruoyao wrote:
> > On 2020-05-26 18:17 +0100, Ken Moffat wrote:
> > > I'm trying to discover why two tests in the testsuite for 'check'
> > > always fail for me. I've now got a response that the tests raise
> > > SIGFPE but do not receive it. The example is
> > >
> > > ken@plexi ~/check-debug $cat test.c
> > > #include <stdio.h>
> > >
> > > #include <signal.h>
> > >
> > >
> > > int main() {
> > >
> > > printf("Before\n");
> > >
> > > raise(SIGFPE);
> > >
> > > printf("After\n");
> > >
> > > return 0;
> > >
> > > }
> > >
> > > followed by gcc test.c ; ./a.out
> > >
> > > That should terminate on the signal, but for me it doesn't:
> > >
> > > ken@plexi ~/check-debug $./a.out
> > > Before
> > > After
> > >
> > >
> > > However, if I try a division by zero I do get the exception:
> > >
> > > ken@plexi ~/check-debug $cat divbyzero.c
> > > #include <stdio.h>
> > >
> > > #include <signal.h>
> > >
> > >
> > > int main() {
> > >
> > > int a = 1000;
> > > int z = 0;
> > > int result;
> > >
> > > printf("Before\n");
> > >
> > > //raise(SIGFPE);
> > > result = a / z;
> > >
> > > printf("After\n");
> > >
> > > return result;
> > >
> > > }
> > >
> > > gcc -o divbyzero divbyzero.c
> > >
> > > ken@plexi ~/check-debug $./divbyzero
> > > Before
> > > Floating point exception
> > >
> > >
> > > Any clues to how I can find what is causing this breakage, please ?
> > > It seems to happen on all my machines.
> >
> > If SIGFPE is somehow masked by sigprocmask, this phenomenon would
> > happen. The
> > SIGFPE raised by raise() will be masked, but the SIGFPE produced by 1/0 is
> > still
> > undefined behavior (on x86_64 Linux normally "as if" a SIGFPE is received).
> >
> > And, the signal mask set with sigprocmask is inherited during fork() and
> > preserved during exec(). So if your shell or init process masked SIGFPE for
> > some reason (intentionally or mistakenly) this will happen.
> >
> > Try to examine the signal mask:
> >
> > #include <stdio.h>
> > #include <signal.h>
> >
> > int main()
> > {
> > sigset_t ss;
> > sigprocmask(SIG_BLOCK, NULL, &ss);
> > if (sigismember(&ss, SIGFPE))
> > puts("oops! SIGFPE is masked!");
> > else
> > puts("SIGFPE is not masked.");
> > return 0;
> > }
>
> Nice code Xi. When I ran this I got 'SIGFPE is not masked'. And when I
> ran Ken's code, I got:
>
> Before
> Floating point exception
>
> Ken sometimes does unusual things, but I'll note on 'man 7 signal' there
> is a section:
>
> BUGS
> There are six signals that can be delivered as a consequence of a
> hardware exception: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and
> SIGTRAP. Which of these signals is delivered, for any given
> hardware exception, is not documented and does not always make
> sense.
That's when these signals are generated by CPU. But Ken is raising SIGFPE with
raise() so it should be delivered.
> I note that FPE stands for Floating Point Exception, but Ken is doing an
> integer divide. It could be a HW architecture issue.
I think the name "floating point exception" is just historical. On "modern"
x86/x86-64 Linux it's usually caused by integer division by 0. Ironically
floating division by 0 (1.0 / 0.0) doesn't cause SIGFPE - the result is just
INF.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
