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.
I note that FPE stands for Floating Point Exception, but Ken is doing an
integer divide. It could be a HW architecture issue.
-- Bruce
--
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
