On Wed, May 27, 2020 at 12:43:26PM +0800, Xi Ruoyao wrote:
>
> 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;
> }
Thanks, but no joy:
ken@plexi ~ $./sigmask
SIGFPE is not masked.
I had found mentions of masking the signal before I first asked, and
it seemed to me that some C code would be needed to do that, not
something I could accidentally cause by anything in my bash setup.
I'm using bash and sysvinit, with the book's instructions. So
thanks for giving me a way to confirm that this is not a symptom of
a vulnerability :)
More generally, yes, I do make variations and particularly I drop
debug info (old habit, my systems try to be small and backed up -
it's the backup space that is the problem). When I first noticed
this a bit over two years ago, I think I was using CFLAGS of -O2 or
perhaps -O2 -march=native. After last year I moved on my main
desktop machines to -O3 and -march=native.
When the -O0 override in glibc errored, I changed that to -O1 (still
with -march=native). Tests on bash still showed the SIGFPE falure,
but I suspect I need to boot the system to properly test it.
Unfortunately it locked up overnight (fairly common on that box) so
I have not yet got to that stage.
Just to be clear, at the moment I'm only trying to detune glibc.
I'm starting to wonder if -march=native might be implicated, but the
machine where this originated, and where I ran the sigmask check, is
a haswell which ought to be common enough for -march=native to not
do anything weird.
Of course, if it was an arm then raising sigfpe is known to be
unreliable. But it ought to be reliable on x86_64 unless there is
some weird code in either glibc or the kernel which might fail if
some kernel config option is deselected.
(Still thinking aloud).
ĸen
--
Do you not know that, what you belittle by the name tree is but the
mere four-dimensional analogue of a whole multidimensional universe
which - no, I can see you do not. -- Druellae (a Dryad)
--
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
