Can't set executable stack size during compilation

Can't set executable stack size during compilation

[Erich]

I have a problem setting the stack size of a GNAT made program during
compilation. It is a bit memory extensive and sometimes yields a
storage error with the standard stack size (I'd prefer to avoid the
heap for the time being).

None of the methods described here:

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Setting-Stack-Size-from-gnatlink.html

so far had any effect on the executable. (The -Xlinker version yields
a linker error when set as link option in GNAT-GPS.) Using ulimit -s
32768 manually in the shell solves the problem, but this is not a good
option for final deployment.

I'd appreciate any help!


Best,

Erich

----
P.S. Running 64bit Ubuntu 10.04 with gcc 4.4.3 and GNAT-GPS 4.3.5 from
the Ubuntu 10.04 package as IDE. The version of GNAT used:

gnatls -v

GNATLS 4.4.3
Copyright (C) 1997-2008, Free Software Foundation, Inc.

Source Search Path:
   <Current_Directory>
   /usr/lib/gcc/x86_64-linux-gnu/4.4.3/adainclude/


Object Search Path:
   <Current_Directory>
   /usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/


Project Search Path:
   <Current_Directory>
   /usr/share/ada/adainclude/

Re: Can't set executable stack size during compilation

[Georg Bauhaus]

On 04.01.12 16:49, Erich wrote:
> I have a problem setting the stack size of a GNAT made program during
> compilation. It is a bit memory extensive and sometimes yields a
> storage error with the standard stack size (I'd prefer to avoid the
> heap for the time being).
> 
> None of the methods described here:
> 
> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Setting-Stack-Size-from-gnatlink.html
> 
> so far had any effect on the executable. (The -Xlinker version yields
> a linker error when set as link option in GNAT-GPS.) Using ulimit -s
> 32768 manually in the shell solves the problem, but this is not a good
> option for final deployment.

This looked like having relevant information. The last paragraph
hints at setrlimit(2).

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2008-12/msg00068.html


FWIW, I made a little test program; I think it is legal
but it crashes consistently when translated with GNAT/GCC.
With -fstack-check given, the most unexpected thing to see is a
segmentation fault!

procedure OnStack is

   type Num is range 1 .. 10000;
   type Index is range 1 .. 512;
   type Table is array (Index, Index) of Num;

   type Big is record
      X1, X2, X3, X4, X5: Table;
   end record;

   function Add (A, B : Big) return Big is
      Result : Big;

      function Add_Component (Left, Right: Table) return Table is
         Result : Table;
      begin
         for M in Left'Range loop
            for N in Right'Range loop
               Result (M, N) := Left(M, N) + Right(M, N);
            end loop;
         end loop;
         return Result;
      end Add_Component;

   begin
      Result.X1 := Add_Component (A.X1, B.X1);
      Result.X2 := Add_Component (A.X2, B.X2);
      Result.X3 := Add_Component (A.X3, B.X3);
      Result.X4 := Add_Component (A.X4, B.X4);
      Result.X5 := Add_Component (A.X5, B.X5);
      return Result;
   end Add;

   X, Y: Big;
   Data : Big;
begin
   Data := Add (X, Y);
end OnStack;

Re: Can't set executable stack size during compilation

[Bill Findlay]

On 04/01/2012 16:27, in article
4f047e0f$0$6582$9b4e6d93@newsspool3.arcor-online.net, "Georg Bauhaus"
<rm.dash-bauhaus@futureapps.de> wrote:
> 
> FWIW, I made a little test program; I think it is legal
> but it crashes consistently when translated with GNAT/GCC.
> With -fstack-check given, the most unexpected thing to see is a
> segmentation fault!

With GNAT GPL 2011 on OS X:

> /Users/wf/KDF9/emulation/Build: ./onstack
> 
> raised STORAGE_ERROR : stack overflow

It's not legal, of course: it fetches unassigned variables,
though that is nothing to do with the stack overflow.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Can't set executable stack size during compilation

[Georg Bauhaus]

On 1/4/12 6:22 PM, Bill Findlay wrote:
> On 04/01/2012 16:27, in article
> 4f047e0f$0$6582$9b4e6d93@newsspool3.arcor-online.net, "Georg Bauhaus"
> <rm.dash-bauhaus@futureapps.de>  wrote:
>>
>> FWIW, I made a little test program; I think it is legal
>
> It's not legal, of course: it fetches unassigned variables,

I had though that variables not assigned (uninitialized?)
won't be the subject of legality rules (and would otherwise
have to be rejected during compilation or post-compilation)?

If the program did perform I/O, its executions is likely
to have error, yes.

Re: Can't set executable stack size during compilation

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:4f04c66c$0$6625$9b4e6d93@newsspool2.arcor-online.net...
> On 1/4/12 6:22 PM, Bill Findlay wrote:
>> On 04/01/2012 16:27, in article
>> 4f047e0f$0$6582$9b4e6d93@newsspool3.arcor-online.net, "Georg Bauhaus"
>> <rm.dash-bauhaus@futureapps.de>  wrote:
>>>
>>> FWIW, I made a little test program; I think it is legal
>>
>> It's not legal, of course: it fetches unassigned variables,
>
> I had though that variables not assigned (uninitialized?)
> won't be the subject of legality rules (and would otherwise
> have to be rejected during compilation or post-compilation)?
>
> If the program did perform I/O, its executions is likely
> to have error, yes.

Formally, an "illegal" program is one that fails a Legality Rule, and those 
are checked at compile-time.

I suspect that Bill has being more informal, but even then, an Ada program 
can use an uninitialized value without the program being bad (erroneous); 
doing so might only be a bounded error and may not raise any exception at 
all depending on what is actually done. ("Invalid" values are allowed so 
long as they are not used to do array indexing and some other things.)

                                   Randy.

Re: Can't set executable stack size during compilation

[Bill Findlay]

On 05/01/2012 01:06, in article je2t32$20h$1@munin.nbi.dk, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

> "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message
> news:4f04c66c$0$6625$9b4e6d93@newsspool2.arcor-online.net...
>> On 1/4/12 6:22 PM, Bill Findlay wrote:
>>> On 04/01/2012 16:27, in article
>>> 4f047e0f$0$6582$9b4e6d93@newsspool3.arcor-online.net, "Georg Bauhaus"
>>> <rm.dash-bauhaus@futureapps.de>  wrote:
>>>> 
>>>> FWIW, I made a little test program; I think it is legal
>>> 
>>> It's not legal, of course: it fetches unassigned variables,
>> 
>> I had though that variables not assigned (uninitialized?)
>> won't be the subject of legality rules (and would otherwise
>> have to be rejected during compilation or post-compilation)?
>> 
>> If the program did perform I/O, its executions is likely
>> to have error, yes.
> 
> Formally, an "illegal" program is one that fails a Legality Rule, and those
> are checked at compile-time.
> 
> I suspect that Bill has being more informal ...

Yes, I wasn't being legalistic, just pragmatic. 8-)

> ... but even then, an Ada program can use an uninitialized value without the
> program being bad (erroneous); doing so might only be a bounded error and
> may not raise any exception at all depending on what is actually done.
> ("Invalid" values are allowed so long as they are not used to do array
> indexing and some other things.)

As it happens, when I ran it I got:

> /Users/wf/KDF9/emulation/Build: ./onstack
> 
> raised CONSTRAINT_ERROR : onstack.adb:19 range check failed

because my default GNAT switches ask it to (attempt to) check for uses of
uninitialized variables.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Can't set executable stack size during compilation

[Georg Bauhaus]

On 1/5/12 5:35 AM, Bill Findlay wrote:

> As it happens, when I ran it I got:
>
>> /Users/wf/KDF9/emulation/Build: ./onstack
>>
>> raised CONSTRAINT_ERROR : onstack.adb:19 range check failed
>
> because my default GNAT switches ask it to (attempt to) check for uses of
> uninitialized variables.

A possible solution of GNAT's stack size issue, an Ada solutions of sorts,
appears to be available with tasking. Move the computation to a task
and add

    pragma Storage_Size (Minimum_Storage_Size);

in the task's declaration, thus

procedure Run_in_Task is

    type Num is range 1 .. 10000;
    type Index is range 1 .. 512;
    type Table is array (Index, Index) of Num;

    type Big is record
       X1, X2, X3, X4, X5: Table :=
         (others => (others => Num'First));
    end record;

    Minimum_Storage_Size : constant := 11_000_000;
    --  task's storage size; addressing stack size issues with GNAT
    --  about equal to 512 * 512 * 2 * 5 * 4

    task Onstack is
       pragma Storage_Size (Minimum_Storage_Size);
    end Onstack;

    task body Onstack is separate;

begin
    null;
end Run_in_Task;

separate (Run_in_Task)
task body OnStack is

    function Add (A, B : Big) return Big is
       Result : Big;

       function Add_Component (Left, Right: Table) return Table is
          Result : Table;
       begin
          for M in Left'Range loop
             for N in Right'Range loop
                Result (M, N) := Left(M, N) + Right(M, N);
             end loop;
          end loop;
          return Result;
       end Add_Component;

    begin
       Result.X1 := Add_Component (A.X1, B.X1);
       Result.X2 := Add_Component (A.X2, B.X2);
       Result.X3 := Add_Component (A.X3, B.X3);
       Result.X4 := Add_Component (A.X4, B.X4);
       Result.X5 := Add_Component (A.X5, B.X5);
       return Result;
    end Add;

    X, Y: Big;
    Data : Big;
begin
    Data := Add (X, Y);
    pragma Inspection_Point (Data);
end OnStack;

Re: Can't set executable stack size during compilation

[Erich]

On Jan 5, 10:19 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:

> A possible solution of GNAT's stack size issue, an Ada solutions of sorts,
> appears to be available with tasking. Move the computation to a task
> and add
>
>     pragma Storage_Size (Minimum_Storage_Size);

I think I'll go for this solution instead of setrlimit, because I was
considering to splitting up the problem into several tasks for
multicore CPUs anyway.

Thanks a lot for the detailed example!

--Erich

Re: Can't set executable stack size during compilation

[Jerry]

On Jan 4, 9:27 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 04.01.12 16:49, Erich wrote:
>
> > I have a problem setting the stack size of a GNAT made program during
> > compilation. It is a bit memory extensive and sometimes yields a
> > storage error with the standard stack size (I'd prefer to avoid the
> > heap for the time being).
>
> > None of the methods described here:
>
> >http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Setting-Stack-Size-from-gn...
>
> > so far had any effect on the executable. (The -Xlinker version yields
> > a linker error when set as link option in GNAT-GPS.) Using ulimit -s
> > 32768 manually in the shell solves the problem, but this is not a good
> > option for final deployment.
>
> This looked like having relevant information. The last paragraph
> hints at setrlimit(2).
>
<snip>

setrlimit is discussed here:
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ae395e5c11de7bc9/bda8d61bd3a66ee9?hl=en&q=Jerry+stack&lnk=nl&

Jerry

Re: Can't set executable stack size during compilation

[Mark Lorenzen]

On 4 Jan., 17:27, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> [...]
> FWIW, I made a little test program; I think it is legal
> but it crashes consistently when translated with GNAT/GCC.
> With -fstack-check given, the most unexpected thing to see is a
> segmentation fault!

If the environment task uses too much stack space, it may not be
possible to raise an exception or unwind the raised exception (i don't
know which). Probably because raising or unwinding an exception uses
some stack space itself. See
http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_24.html

[QUOTE]
For the environment task, the stack size depends on system defaults
and is unknown to the compiler. Stack checking may still work
correctly if a fixed size stack is allocated, but this cannot be
guaranteed. To ensure that a clean exception is signalled for stack
overflow, set the environment variable GNAT_STACK_LIMIT to indicate
the maximum stack area that can be used, as in:

SET GNAT_STACK_LIMIT 1600

The limit is given in kilobytes, so the above declaration would set
the stack limit of the environment task to 1.6 megabytes. Note that
the only purpose of this usage is to limit the amount of stack used by
the environment task. If it is necessary to increase the amount of
stack for the environment task, then this is an operating systems
issue, and must be addressed with the appropriate operating systems
commands.
[/QUOTE]

Best Regards,

Mark L

Re: Can't set executable stack size during compilation

[Jerry]

On Jan 4, 8:49 am, Erich <j...@peppermind.com> wrote:
> I have a problem setting the stack size of a GNAT made program during
> compilation. It is a bit memory extensive and sometimes yields a
> storage error with the standard stack size (I'd prefer to avoid the
> heap for the time being).
>
There has been discussed several times here a very cool and elegant
way to allocate from the heap without trashing your program or re-
writing code so that it can accept pointers as arguments. The link

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ae395e5c11de7bc9/bda8d61bd3a66ee9?hl=en&q=Jerry+stack&lnk=nl&

mentions this.

However, I have found that even with large arrays allocated from the
heap using pointers, when using the "-" operator (for example) on the
arrays, large amounts of memory might be required from the stack. I
believe that this is because the intermediate result result of "-" is
taken from the stack. You might be able to write your own "-" overload
in that case and see if it behaves differently.

Jerry