GNAT and -fstack-check, does it work?

GNAT and -fstack-check, does it work?

[Niklas Holsti]

In a recent or current c.l.a thread on "ada compiler" the OP was 
advised to use the gnatmake options -gnato and -fstack-check to 
make GNAT a full Ada compiler, with run-time checks for arithmetic 
overflow and stack overflow, respectively. I'm not sure if 
-fstack-check is enough, or is working as expected.

I have been using those options for a while, but I was recently hit 
by a bug in which stack overflow made the program abort with 
Segmentation Violation (signal 11 = SIGSEGV) instead of the 
expected Storage_Error exception. This is under Debian Sarge with 
gnat 3.15p. In fact the Ada program simply stopped with no error 
messages, and I had to run it under the Linux "strace" tool before 
I found out that it was killed by SIGSEGV. (I found out later that 
GDB also shows the SIGSEGV, at least from a post-mortem core dump.)

While investigating this problem I learned some things:

- According to the GNAT User Guide (at least the version
   at gcc.gnu.org) the option -fstack-check does not always
   work for the stack of the environment task, that is, for
   the "main" stack, because GNAT may not know the actual
   size allocated (or allocatable) for this stack. You must
   also set the environment variable GNAT_STACK_LIMIT to
   the size of the stack (in kilobytes) when the compiled
   Ada program is started.

- The behaviour on my system depends on whether the Ada
   program is linked dynamically (using shared libraries) or
   statically. With dynamic libraries the environment task
   stack limit is set by the shell command "ulimit -s". My
   default ulimit is 8 MB which was enough to avoid stack
   overflow in this case. With static libraries the stack
   limit on my system seems to be around 2 MB even if a
   larger "ulimit" is used or a larger value is set with
   the "-d" option for gnatbind. This smaller size led to
   stack overflow and SIGSEGV in my program. I have seen
   some web references that explain that the 2 MB limit
   occurs because some versions of libpthread.a have
   hard-coded stack size for threads, and my version
   seems to have that.

- There is an open GCC bug (bug 13757, "-fstack-check
   causes segfaults") that says that "-fstack-check" can
   generate buggy code that *sometimes* causes a
   segfault, depending on the placement of the stack
   relative to page boundaries, thus depending on the
   length of the environment variables, the length of
   the command name (program path name), and whether the
   program is invoked directly or via GDB. Ugh.

I'd appreciate to hear from the c.l.a crowd:

- Does -fstack-check work for you? Which versions of
   GNAT, which systems? Do you need to set GNAT_STACK_LIMIT
   too?

- Is the behaviour different for dynamic linking and
   static linking? Which GNAT, which system?

- Have you had problems like those described in bug 13757?
   Do you know if that bug affects GNAT?

Thanks...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: GNAT and -fstack-check, does it work?

[Stefan Bellon]

On Sun, 11 Nov, Niklas Holsti wrote:

[-gnato -fstack-check]
> I have been using those options for a while, but I was recently hit 
> by a bug in which stack overflow made the program abort with 
> Segmentation Violation (signal 11 = SIGSEGV) instead of the 
> expected Storage_Error exception. This is under Debian Sarge with 
> gnat 3.15p.

We are hit by that bug, feature or whatever it is since GNAT 3.15p
onwards (up to GNAT Pro 6.0.2 now). It seems to be some combination of
options. We just decided not to specify -fstack-check. But perhaps it's
something we are missing.

BTW: We are on Debian as well (although always unstable).

> I'd appreciate to hear from the c.l.a crowd:
> 
> - Does -fstack-check work for you? Which versions of
>    GNAT, which systems? Do you need to set GNAT_STACK_LIMIT
>    too?

I see something like ...

Execution terminated by unhandled exception
Exception name: STORAGE_ERROR
Message: stack overflow (or erroneous memory access)
Call stack traceback locations:
0x43d76e99

... whenever I execute an application compiled with our switches:

  -gnat05 -gnata -gnatef -gnatf -gnatn -gnatU -gnatwa -gnatwl
  -gnatyaAbdefhiklmnprtx -O0 -g -gnato -fstack-check

> - Is the behaviour different for dynamic linking and
>    static linking? Which GNAT, which system?

We have not done static builds for a long time, but IIRC we had the
problem then as well, but don't quote me on that. GNAT versions ... see
above.

> - Have you had problems like those described in bug 13757?
>    Do you know if that bug affects GNAT?

We have never used -fstack-check with C code, I'm afraid.

-- 
Stefan Bellon

Re: GNAT and -fstack-check, does it work?

[Georg Bauhaus]

Stefan Bellon wrote:
> On Sun, 11 Nov, Niklas Holsti wrote:
>
>> - Have you had problems like those described in bug 13757?
>>    Do you know if that bug affects GNAT?
> 
> We have never used -fstack-check with C code, I'm afraid.

-fstack-check and then calling C functions caused me trouble
a few years ago. Will not using -fstack-check be o.K. with
Ada programs in case off-bound access to local arrays
(Strings, whatever) will cause SIGSEGV instead of raising
an occurrence of expception Storage_Error?

Will it be o.K. for GNAT compiled Ada programs to cause
segmentation violations instead of storage error when
some recursion needs to be run more often than preset stack
bounds will permit?

I don't want to start turning all local arrays into
pointers just because of an unclear situation with
-fstack-check. I also do not like an implementation that
is in the way of recursive subprograms.

If I could afford dropping recursion (and other features
of Ada), I'd be using SPARK. But I need Ada for writing
general purpose programs.

Re: GNAT and -fstack-check, does it work?

[Niklas Holsti]

Stefan Bellon wrote:
> On Sun, 11 Nov, Niklas Holsti wrote:
> 
> [-gnato -fstack-check]
> 
>>I have been using those options for a while, but I was recently hit 
>>by a bug in which stack overflow made the program abort with 
>>Segmentation Violation (signal 11 = SIGSEGV) instead of the 
>>expected Storage_Error exception. This is under Debian Sarge with 
>>gnat 3.15p.
> 
> 
> We are hit by that bug, feature or whatever it is since GNAT 3.15p
> onwards (up to GNAT Pro 6.0.2 now). It seems to be some combination of
> options. We just decided not to specify -fstack-check. But perhaps it's
> something we are missing.
> 
> BTW: We are on Debian as well (although always unstable).

Thanks for this information. Can you also say if this happens with 
the environment task stack, or some other (declared) task stack? 
Did you set the GNAT_STACK_LIMIT variable?

>>I'd appreciate to hear from the c.l.a crowd:
>>
>>- Does -fstack-check work for you? Which versions of
>>   GNAT, which systems? Do you need to set GNAT_STACK_LIMIT
>>   too?
> 
> 
> I see something like ...
> 
> Execution terminated by unhandled exception
> Exception name: STORAGE_ERROR
> Message: stack overflow (or erroneous memory access)
> Call stack traceback locations:
> 0x43d76e99
> 
> ... whenever I execute an application compiled with our switches:
> 
>   -gnat05 -gnata -gnatef -gnatf -gnatn -gnatU -gnatwa -gnatwl
>   -gnatyaAbdefhiklmnprtx -O0 -g -gnato -fstack-check

Do I understand correctly that this happens even when your 
application does not really cause stack overflow? That is, you get 
a *spurious* report of stack overflow?

In my case, the stack overflow was real (a problem in the size 
computed for a local array in my application, now fixed) but the 
reaction to the overflow was not what I expected, and shows that 
-fstack-check did not detect the overflow, perhaps because I did 
not set GNAT_STACK_LIMIT.

If I set GNAT_STACK_LIMIT to a value smaller than the attempted 
stack allocation I do get a Storage_Error and a stack-overflow 
message, showing that in my system -fstack-check depends on 
GNAT_STACK_LIMIT, at least for the environment task.

>>- Have you had problems like those described in bug 13757?
>>   Do you know if that bug affects GNAT?
> 
> 
> We have never used -fstack-check with C code, I'm afraid.

Well, bug 13757 may be a bug in the GCC back-end and then it could 
affect also Ada programs. If -fstack-check (in combination with 
some other options) causes spurious stack-overflow exceptions in 
your applications, it might be related to this bug. But your 
spurious exceptions seem to be more reliable (systematic) than the 
description of bug 13757 suggests, where it speaks of stack-frame 
alignments depending on the length of the program name and so on.

My conclusions so far: I will reconsider the use of -fstack-check 
and static linking when I upgrade from GNAT 3.15p to the new Debian 
GNAT.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: GNAT and -fstack-check, does it work?

[Stefan Bellon]

On Wed, 14 Nov, Niklas Holsti wrote:
> Stefan Bellon wrote:

> > BTW: We are on Debian as well (although always unstable).
> 
> Thanks for this information. Can you also say if this happens with 
> the environment task stack, or some other (declared) task stack? 
> Did you set the GNAT_STACK_LIMIT variable?

I tried with and without setting of GNAT_STACK_LIMIT. I set it to
several values, always same result.

> > Exception name: STORAGE_ERROR
[...]
> > ... whenever I execute an application compiled with our switches:
[...]
> 
> Do I understand correctly that this happens even when your 
> application does not really cause stack overflow? That is, you get 
> a *spurious* report of stack overflow?

Yes. Without -fstack-check the application runs without any trouble.

> But your 
> spurious exceptions seem to be more reliable (systematic) than the 
> description of bug 13757 suggests, where it speaks of stack-frame 
> alignments depending on the length of the program name and so on.

Yes, it is very reliable, but on the other hand, our project is far
from simple but has a very complex setup. Turning this into a small
reproducer is nothing I can do easily.

-- 
Stefan Bellon