Bug 91543 - [11/12/13/14 Regression] nf failure ( Handling stack overflow more sensibly
Summary: [11/12/13/14 Regression] nf failure ( Handling stack overflow more sensibly
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 10.0
: P4 normal
Target Milestone: 11.5
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-25 21:07 UTC by Thomas Koenig
Modified: 2023-07-07 10:35 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-07-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2019-08-25 21:07:18 UTC
I've just been bitten by a strange segfault, which turned out to be
due to insufficient stack space with -Ofast (running nf from the
Polyhedron benchmarks).

We really need a sensible error message when that happens.
"Insufficient stack space, aborting\n" would already be enough.

Of course, not every segmentation violation is a stack overflow :-|

So, a strategy could be:

On startup, prepare a heap buffer with a sensible error message.
Also, stash away the starting address of the stack, its size and
other pertinent information, and set up a signal handler for SIGSEGV
using sigalstack().

On receiving a SIGSEGV, we could check if the segfaulting address
is indeed near the end of the stack, and if that is the case,
just do a write(2,...) with our prepared error message and exit.
Otherwise, just do the normal thing (usually, abort).

We could also increase the stack size, to avoid hitting that
particular error too soon.

What do people think?
Comment 1 Richard Biener 2019-08-26 08:04:03 UTC
Did you try if -fstack-clash-protection provides a better failure mode?  It
might be required to reliably detect that "end of the stack" case.
Comment 2 Thomas Koenig 2019-08-26 15:57:03 UTC
(In reply to Richard Biener from comment #1)
> Did you try if -fstack-clash-protection provides a better failure mode?  It
> might be required to reliably detect that "end of the stack" case.

No, just a SIGSEGV.
Comment 3 Thomas Koenig 2019-09-14 12:35:11 UTC
We could look at https://www.gnu.org/software/libsigsegv/ how to
do this, or maybe even include this as a prerequisite for libgfortran.

Haven't looked in detail yet...
Comment 4 Thomas Koenig 2019-10-04 20:42:22 UTC
The nf failure is a regression in itself, so we should mark it as such,
and we should definitely try to fix this before gcc 10 comes out.
Comment 5 Janne Blomqvist 2019-10-08 10:12:25 UTC
Is https://gcc.gnu.org/viewcvs?rev=274264&root=gcc&view=rev the culprit?

And if so, should be reduce it back to the previous default of 32 kB?

(A bummer, I had hoped to eventually make -frecursive the default..)
Comment 6 Jeffrey A. Law 2020-01-27 23:39:14 UTC
For the case where you want some kind of recovery, -fstack-check is a better approach than -fstack-clash-protection as -fstack-check ensures there's always a page available to the segfault handler.
Comment 7 Jakub Jelinek 2020-05-07 11:56:20 UTC
GCC 10.1 has been released.
Comment 8 Dominique d'Humieres 2020-07-20 10:59:12 UTC
I don't see that.
Comment 9 Richard Biener 2020-07-23 06:51:49 UTC
GCC 10.2 is released, adjusting target milestone.
Comment 10 Richard Biener 2021-04-08 12:02:22 UTC
GCC 10.3 is being released, retargeting bugs to GCC 10.4.
Comment 11 Jakub Jelinek 2022-06-28 10:38:16 UTC
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Comment 12 Richard Biener 2023-07-07 10:35:54 UTC
GCC 10 branch is being closed.