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

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .